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 :-)
> >
> >>
> >
>
>