Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Thu, 08 March 2018 01:48 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17F1200E5 for <tls@ietfa.amsl.com>; Wed, 7 Mar 2018 17:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKjTkAHjm1nf for <tls@ietfa.amsl.com>; Wed, 7 Mar 2018 17:48:05 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9316126B6E for <tls@ietf.org>; Wed, 7 Mar 2018 17:48:01 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id v124so5074685qkh.11 for <tls@ietf.org>; Wed, 07 Mar 2018 17:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0kKb/6KMAwZaxoYv8QBi75Efjznk0NVPPLQC+bSIC9g=; b=wf/rVddPC4ssqOlJeBtj32kOS8YJB9hlo/FdXHIokg3w93Y+5JaOZ87Ajxw9Wzn4w8 3n6xFDmIe8pDQMfYcB0JXF3RzlnbsJVTgUUoLZaRr63BMAFVOnb7TUVyLlHLcCZd7KAu kmuENwo/QHo+vFgDtjR+QmUePAZMxf9SYfeq2CpkX9YeOTzsw6pF2oZGl1U2zBC9Wbhe Jhx8nOjLCws4D/wEQNlfHAahMDNG1guW2YgUtYxz8tEoOqKmg6Qai06Z5ZuuYKYdcT2M RRT8NtK5RdbD7hqqQOAUKER6HcUUs7iGsyAHZ9zLqApbcUZ2Yab0lxgf0zIFrjLKDnpg RtMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0kKb/6KMAwZaxoYv8QBi75Efjznk0NVPPLQC+bSIC9g=; b=cgrq+3NLBR038JWkoNvTbiGncZvIUz9DCNlO/KnysA2KCjXAoPncN2LaEH0EinzUOD ISHA55np9eijcDbVa7OU5oerh5CrEz13FeChUfY+QJiD9eWmHrPcxTBrOZ0oEa+RTLQw JDytyBCVldxrAjOesFvTx1i/cXudP8thzefHOXzeZDVCLcA5BJbB6A03Iy8jkZY7ozpF 1pQ6xIFtgk36XvYoIUWeL8O8h4Vkal2NpSf9dpp8KRYAboSgQY2SNjXiaTLOYmJ3Z+Oq OpUmHP9lfh+4i92XcuJN/Qywf01C4T96/i2N0DQFkX1uy9MWo2EU9be4Kwz4aA9tLurV Yi7g==
X-Gm-Message-State: AElRT7GTWX7rtzJOQIfmTyaLdJqCJ7vqUCbzcMfQJ/oLCdY32lw68+PR lYKx80FlUOe8FEPnbSarudmSvTPtOBhEGmkyNUFUZA==
X-Google-Smtp-Source: AG47ELust7/V9s/XLJ3+6T+41iOIKFHjddYZk/bSWJ8IiIahuStKLffcD0N9qQrWCPOzxqk6c2Y77bGVR9CG5oDJXm0=
X-Received: by 10.55.103.1 with SMTP id b1mr36502399qkc.98.1520473680670; Wed, 07 Mar 2018 17:48:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Wed, 7 Mar 2018 17:47:20 -0800 (PST)
In-Reply-To: <26718E8E-5F81-43CC-A127-E362BD5C4706@sn3rd.com>
References: <152035726289.28354.15009436908256456026.idtracker@ietfa.amsl.com> <43224E51-EBF9-4471-B133-B118DA1CE05A@sn3rd.com> <362DB102-B772-4797-80A6-E043F8A3BFEF@nostrum.com> <26718E8E-5F81-43CC-A127-E362BD5C4706@sn3rd.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 07 Mar 2018 17:47:20 -0800
Message-ID: <CABcZeBMkwncALJqEgCBMxx3UuYCq7kqvDxS9yoFDvdMxsUW-xQ@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>, draft-ietf-tls-tls13@ietf.org, tls-chairs <tls-chairs@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0571b8a095cc0566dcdd1e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ex4aIussh9TB5TcHJciEU7RpXco>
Subject: Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Thu, 08 Mar 2018 01:48:07 -0000
On Wed, Mar 7, 2018 at 4:39 PM, Sean Turner <sean@sn3rd.com> wrote: > > > > On Mar 7, 2018, at 16:35, Ben Campbell <ben@nostrum.com> wrote: > > > > > > > >> On Mar 7, 2018, at 2:49 PM, Sean Turner <sean@sn3rd.com> wrote: > >> > >> > >> > >>> On Mar 6, 2018, at 12:27, Ben Campbell <ben@nostrum.com> wrote: > >>> > >>> 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.) > >> > >> No - this is just how it works TLS - clients send the ClientHello > message first ;) > > > > I assume your response to mean that the point is merely that ClientHello > is the first message of the TLS handshake. As worded, I think some readers > might interpret this to mean that the client can send no other data at any > layer prior to ClientHello. > > Well this is about TLS :) But, maybe r/its first message/its first TLS > handshake message ? > > >>> §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? > >> > >> In short kinda, sorta yes: §s4.2.1 includes the following: > >> > >> Implementations of TLS 1.3 which choose to support prior versions of > >> TLS SHOULD support TLS 1.2. > > > > That still says “which choose to support” > > Right so there might be some implementations that choose to not support > prior versions. > Indeed, I am aware of at least one. -Ekr > > >> Not sure it’s inconsistent given that the 2nd quote is about the server > needs to do with the information it’s getting from the client. > > > > I’m still confused. Is the server allowed to refuse to negotiate 1.2? Or > is the exception in §4.2.1 supposed to apply to all of the related MUSTs? > > Yes - TLS servers are allowed to refuse to negotiate earlier version; > that’s deciding to not follow the SHOULD in §s4.2.1. If they negotiate an > earlier version then do that version that’s what’s in §s4.1.2 and in §4.2.3. > > >>> §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. > >> > >> I think it’ll be useful for about as long as it takes for them to rev > their code bases, which I am sure hoping is faster than the 6 or so weeks > it’ll take for this draft to get to through the RFC editor’s queue. > > > > Okay. > > > >> > >>> §D.5: This section has a lot of normative requirements that seem > important. I > >>> wonder why it has been relegated to an appendix. > >> > >> §D.5 is about backward compatibility and though we negotiations with > 1.2 is a SHOULD we say nada about earlier versions. And, we don’t want to > say anything about earlier versions. And, some of this is technically > repeated from other RFCs, eg. 5768 and 6176 saying don’t do SSL2/3. So, it > ended up in an appendix. > > > > Okay. > > > >> > >>> *** 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”. > >> > >> (grammar police are banging on my door as we speak) > > > > Well, my comment was labeled as editorial or nit :-) > > > >> So is the which clause restrictive or non restrictive? I’m going with > this this clause being restrictive (hence no comma). > > > > I’ll let the grammar police at your door debate the merits of “which” vs > “that” for restrictive clauses :-) > > See the response to Adam’s comment :). But, yeah the RFC editor will > definitely school me when the time comes. > > >>> §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? > >> > >> Yes that is the intent. > > > > Okay. Would it be reasonable to offer guidance about when might want to > treat this as fatal even though it would have been possible to use the PSK > without (EC)DHE? > > So the fatal error is when the client and server are trying to negotiate > (EC)DHE parameters and there’s no overlap in the supported_groups. This > would occur in the “normal” case when the client is anonymous (i.e., client > only sends ClientHello+key_share and no psk_key_exchange_modes/pre_shared_key) > or when the client is using PSK+(EC)DHE for client authentication. But, > that is described in the previous paragraph. Maybe another way to say it > is: normally you’d throw an error if supported_groups didn’t overlap, but > here since you’re not using them because you’re doing PSK-only you don’t. > > >>> §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? > >> > >> Yes - once we’ve gotten the a-okay from IANA, well as the RFC editor to > make it just say “has updated” etc. > > > > Okay. > > > >> > >>> §E.2.1: [BDFKPPRSZZ16] : Best citation anchor evar > >> > >> :) > > > > I am trying to decide if that should sound like a “Bill the Cat” > utterance or a sound effect for cartoon violence involving high voltage :-) > > > >> > > > >
- [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