[TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
Ben Campbell <ben@nostrum.com> Tue, 06 March 2018 17:27 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9391201F8; Tue, 6 Mar 2018 09:27:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-tls13@ietf.org, Sean Turner <sean@sn3rd.com>, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.74.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152035726289.28354.15009436908256456026.idtracker@ietfa.amsl.com>
Date: Tue, 06 Mar 2018 09:27:42 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zN0mKIID4xnLYA_Sa8rDRVdKS4w>
Subject: [TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 17:27:43 -0000
Ben Campbell has entered the following ballot position for draft-ietf-tls-tls13-26: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There has clearly been a lot of work put into this. It's a surprisingly understandable document, given its length and the complexity of the subject. I am balloting yes, but I have a few minor comments and nits. None of these are showstoppers, so please do with them as you will. *** Substantive Comments: §4.1.2, first paragraph: " When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message. " Is that intended to prohibit the use of STARTTLS or similar application layer patterns? (To be clear, this is not an objection, just a clarification request.) §4.1.2, legacy_compression_methods: "Note that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS." Is that intended to require TLS 1.3 servers to always be willing and able to negotiate 1.2? §4.2.1 has a similar assertion: "If this extension is not present, servers which are compliant with this specification MUST negotiate TLS 1.2 or prior as specified in [RFC5246], even if ClientHello.legacy_version is 0x0304 or later." But §4.2.3 says: "Note that TLS 1.2 defines this extension differently. TLS 1.3 implementations willing to negotiate TLS 1.2 MUST behave in accordance with the requirements of [RFC5246] when negotiating that version." ... which seems inconsistent (noting that this paragraph talks about "implementations" rather than "servers", so perhaps there's a subtle difference? §4.2.1.1: The section is marked for removal. Do you expect that RFC implementations will ever need to interop with draft implementations? If so, the information in this section may continue to be useful for some time. §D.5: This section has a lot of normative requirements that seem important. I wonder why it has been relegated to an appendix. *** Editorial Comments and nits: §2: "If (EC)DHE key establishment is in use, then the ServerHello contains a "key_share" extension with the server’s ephemeral Diffie-Hellman share which MUST be in the same group as one of the client’s shares. " missing comma prior to "which". §4.1.1: "Note that if the PSK can be used without (EC)DHE then non- overlap in the "supported_groups" parameters need not be fatal, as it is in the non-PSK case discussed in the previous paragraph." I read "need not be fatal" to mean that it may still be fatal at times. Is that the intent? §11: The IANA considerations have a number of constructions similar to "SHALL update/has updated". Is that text expected to collapse to "has updated" at some point? §E.2.1: [BDFKPPRSZZ16] : Best citation anchor evar
- [TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-… Ben Campbell
- Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tl… Sean Turner
- Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tl… Ben Campbell
- Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tl… Sean Turner
- Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tl… Eric Rescorla
- Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tl… Eric Rescorla