ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec
draft-ietf-ipsecme-chacha20-poly1305-12

[Ballot comment]
This is easier than usual to read for this sort of draft :-)

-- Section 1, 1st paragraph:
I concur with Stephen's comment. Furthermore, this entire paragraph pretty much reads like advertising copy. Can it be toned down a bit?

-- 8.1 (Normative References)

The reference to [RFC7539]  is a normative downref. I don't see it on the downref registry, nor was it mentioned in the last call notice. (For the record, I think it's a reasonable downref.)

[Ballot comment]

intro: "gold standard" is being a bit too keen IMO, I'd say
toning the language down a bit would be better.

intro: 3DES may be the "only other widely supported" cipher
for IPsec, but that's not true more generally.

section 2 says: "As the ChaCha20 block function is not applied
directly to the plaintext, no padding should be necessary."
That "should" could be confusing as written if a reader thinks
it means their code doesn't have to do padding. It might be
better to e.g. say something like "In theory no padding is
needed for this cipher, however, in keeping with..."

section 3: Is "SHOULD inlude no padding" really right?  I'd
have thought a MAY was better there.  "MUST accept any length"
is also a bit odd - what if I (try:-) add loads of padding?

Appendices: thanks for those - I assume someone checked them
for you? (I didn't:-)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipsecme-chacha20-poly1305-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which must be completed.

In the Transform Type 1 - Encryption Algorithm Transform IDs subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

http://www.iana.org/assignments/ikev2-parameters/

a single value will be registered as follows:

Number: [ TBA ]
Name: ENCR_CHACHA20_POLY1305
ESP Reference: [ RFC-to-be ]
IKEv2 Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ChaCha20, Poly1305 and their use in IKE & IPsec) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'ChaCha20, Poly1305 and their use in IKE & IPsec'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the use of the ChaCha20 stream cipher along
  with the Poly1305 authenticator, combined into an AEAD algorithm for
  the Internet Key Exchange protocol (IKEv2) and for IPsec.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd writeup for draft-ietf-ipsecme-chacha20-poly1305

1. Summary

Paul Hoffman is the document shepherd, and Kathleen Moriarty is the responsible Area
Director.

This document describes the use of the ChaCha20 stream cipher along with the Poly1305
authenticator, combined into an AEAD algorithm for both IKEv2 and IPsec.

2. Review and Consensus

The document was discussed fairly well in the WG, both as an individual draft and then as
a WG document. The WG Last Call elicited good review and changes to the document during,
and after, the WG Last Call.

3. Intellectual Property

The author stated that he does not know of any relevant IPR for this document, and points
out that the algorithms and construction have been proposed earlier.

4. Other Points

The same combination of crypto algorithms are being discussed for use in TLS; however,
this document is only for IKEv2 and IPsec.

Network Working Group                                        J. Klensin
Internet-Draft                                            June 26, 2017
Intended status: Informational
Expires: December 28, 2017

    DNS Privacy, Authorization, Special Uses, Encoding, Characters,
          Matching, and Root Structure: Time for Another Look?
              draft-klensin-dns-function-considerations-03

Abstract

  The basic design of the Domain Name System was completed almost 30
  years ago.  The last half of that period has been characterized by
  significant changes in requirements and expectations, some of which
  either require changes to how the DNS is used or that can be
  accommodated only poorly or not at all.  This document asks the
  question of whether it is time to either redesign and replace the DNS
  to match contemporary requirements and expectations (rather than
  continuing to try to design and implement incremental patches that
  are not fully satisfactory) or to draw some clear lines about
  functionality that is not really needed or that should be performed
  in some other way.

Author's Note

  This draft is intended to draw a number of issues and references
  together in one place and to start a discussion.  It is obviously
  incomplete, particularly with regard to the list of perceived issues
  and deficiencies with that DNS.  To avoid misunderstanding, I don't
  completely believe some of the deficiencies listed below but am
  merely providing information about claims of deficiencies.  Input is
  welcome, especially about what is missing (or plain wrong) and would
  be greatly appreciated.

  This document should be discussed on the IETF list or by private
  conversation with the author.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

Klensin                Expires December 28, 2017              [Page 1]
Internet-Draft                DNS Revisions                    June 2017

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on December 28, 2017.

Copyright Notice

  Copyright (c) 2017 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Table of Contents

  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Background and Hypothesis . . . . . . . . . . . . . . . . . .  4
  3.  Warts and Tensions With The Current DNS . . . . . . . . . . .  5
    3.1.  Multiple address types  . . . . . . . . . . . . . . . . .  5
    3.2.  Matching Part I: Case Sensitivity in Labels and Other
          Anomalies . . . . . . . . . . . . . . . . . . . . . . . .  6
    3.3.  Matching Part II: Non-ASCII ("internationalized") Domain
          Name Labels . . . . . . . . . . . . . . . . . . . . . . .  6
    3.4.  Matching Part III: Label Synonyms, Equivalent Names, and
          Variants  . . . . . . . . . . . . . . . . . . . . . . . .  7
    3.5.  Query Privacy . . . . . . . . . . . . . . . . . . . . . .  9
    3.6.  Alternate Name Spaces for Public Use in the DNS
          Framework: The CLASS Problem  . . . . . . . . . . . . . .  9
    3.7.  Loose Synchronization . . . . . . . . . . . . . . . . . .  9
    3.8.  Private Name Spaces and Special Names . . . . . . . . . .  10
    3.9.  Alternate Query or Response Encodings . . . . . . . . . .  11
    3.10. Distribution and Managment of Root Servers  . . . . . . .  11
    3.11. Identifiers Versus Brands and Other Convenience Names . .  12
    3.12. A Single Hierarchy with a Centrally-controlled Root . . .  13
    3.13. Newer Application Protocols and New Requirements  . . . .  13
      3.13.1.  The Extensions . . . . . . . . . . . . . . . . . . .  13
      3.13.2.  Extensions and Deployment Pressures -- The TXT
                RRTYPE . . . . . . . . . . . . . . . . . . . . . . .  14
      3.13.3.  Periods and Zone Cut Issues  . . . . . . . . . . . .  15

Klensin                Expires December 28, 2017              [Page 2]
Internet-Draft                DNS Revisions                    June 2017

    3.14. Scaling of Reputation and Other Ancillary Information . .  16
    3.15. Tensions among transport, scaling and content . . . . . .  17
  4.  Searching and the DNS - An Historical Note  . . . . . . . . .  17
  5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
  6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
  7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
  8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
    8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
    8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
  Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  25
    A.1.  Changes from version -00 (2017-06-02) to -01  . . . . . .  25
    A.2.  Changes from version -01 (2017-06-06) to -02  . . . . . .  25
    A.3.  Changes from version -02 (2017-06-19) to -03  . . . . . .  25
  Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

  This document explores contemporary expectations of the Internet's
  domain system (DNS) and compares them to the assumptions and
  properties of the DNS design.  It is primarily intended to ask the
  question of whether the differences are causing enough stresses on
  the system, stresses that cannot be resolved satisfactorily by
  further patching, that the Internet community should be considering
  designing a new system, one that is better adapted to current needs
  and expectations, and developing a deployment and transition strategy
  for it.  For those (perhaps the majority of us) for whom actually
  replacing the DNS is too radical to be realistic, the document may be
  useful in two other ways.  It may provide a foundation for discussing
  what functions the DNS should not be expected to support and how
  those functions can be supported in other ways, perhaps via an
  intermediate system that then calls on the DNS or by using some other
  type of database technology for some set of functions while leaving
  the basic DNS functions intact.  Or it may provide a basis for
  "better just get used to that and the way it works&, ipsecme-chairs@ietf.org, paul.hoffman@vpnc.org, draft-ietf-ipsecme-chacha20-poly1305.shepherd@ietf.org, draft-ietf-ipsecme-chacha20-poly1305@ietf.org from "Paul E. Hoffman" <paul.hoffman@vpnc.org>

Shepherd writeup for draft-ietf-ipsecme-chacha20-poly1305

1. Summary

Paul Hoffman is the document shepherd, and Kathleen Moriarty is the responsible Area
Director.

This document describes the use of the ChaCha20 stream cipher along with the Poly1305
authenticator, combined into an AEAD algorithm for both IKEv2 and IPsec.

2. Review and Consensus

The document was discussed fairly well in the WG, both as an individual draft and then as
a WG document. The WG Last Call elicited good review and changes to the document during
the WG Last Call.

3. Intellectual Property

The author stated that he does not know of any relevant IPR for this document, and points
out that the algorithms and construction have been proposed earlier.

4. Other Points

The same combination of crypto algorithms are being discussed for use in TLS; however,
this document is only for IKEv2 and IPsec.