Return-Path: 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 27F5D120025; Wed, 13 Nov 2019 03:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Lg6pSWV7VSt1; Wed, 13 Nov 2019 03:30:20 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 9F78E12001A; Wed, 13 Nov 2019 03:30:20 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id u13so1320065ote.0; Wed, 13 Nov 2019 03:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CRdD5utyDc3oyKjHScwz9aBxCpxcl79EkTNxD8NPgGE=; b=pfMCJ0fNj3yw+BG6VJyMlj/DUp/xwpRWjmCJRAKmxtujiKYf6wLeIuLqJqBvl3JJ0A SKlcS+lmtiqUMM7SjTjhdjoM1HEEDPuIe7gVPXKpwNRda8Ih13EE5vRwEzklVjt1UZq/ 42AoCFMA3KBzFmwI/2otJPSgOLwIvoyU6r/6gqi5GfbjDb9ErM/2V05CtF56JWxMV68l 7PVyMAzPnKaPUNA+L3Oq+vujI3M/yyZZ+pQEiBpJWrlzg08csVcDICILIsZ+H36rw9qx b8D79ZNjPcr3qXsT9XHYxP6juYuHj/CUR0cbhhWCeyIB5NHgfM8DZQkzU2xOro2Pdk0H 8AOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CRdD5utyDc3oyKjHScwz9aBxCpxcl79EkTNxD8NPgGE=; b=QXjg0Q3LBAXb9H+EIsma/tlp4tY4VNRTMAE+ZjNZYXfTMq/tpISOtIcNAqohss7/XR ua1PBeKFwyd+Ve2N3w34WwkfUUkh8RWITng7Ezg4uMF1ZuFGyC6/r5hyMBTOtkoekX+7 r8RaBIIi1IsfQX7bEM3zjE0Fg8p8Nmqm+6nF1FlF+5L4nOqL1kdmTW0PqNFpuWz5sYYi F6m8LH9Bh4ALt9uyz75QUASN16/cnbd7DjAH8J/6EDsa1e+odByYu4B4n/dLoJzoCEP1 Nduk/ivQvRumSjyk/g09F8s25TY3ZQtklRLuPnTyxpKVaG98m+aEzmiDMmXmy3qT6CC+ lxsQ== X-Gm-Message-State: APjAAAVGdl158i4MUdvkiBxPnB+6pBqSCTMioN9Orr3JZepEgE6KCdD2 qXoKUGg8z9HCzWQvuprsfL47EXCIuBfCvM1mbxK6YYtP X-Google-Smtp-Source: APXvYqz+Z7ixIi+qVcfri4UL6xhadrKqjS24dvfYVmtoR/2jfMY/kT1ZWXMADDmwCmGyiy31KKW77cGJwXNhKsYC/rs= X-Received: by 2002:a9d:7219:: with SMTP id u25mr2349110otj.342.1573644619971; Wed, 13 Nov 2019 03:30:19 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> In-Reply-To: <20191111195325.GE32847@kduck.mit.edu> From: Kathleen Moriarty Date: Wed, 13 Nov 2019 06:29:44 -0500 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-tls-oldversions-deprecate.all@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000938306059738b016" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 11:30:23 -0000 --000000000000938306059738b016 Content-Type: text/plain; charset="UTF-8" Hi Ben, Just replying to the parts of the tread that were not responded to already as Stephen will likely be looking at the headers/updates per his message. Thanks for your careful review. On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kaduk wrote: > Hi all, > > This is a "preliminary" review only because there's some strangeness > relating to the Updates: (and Obsoletes:) headers, and any changes there > would make me need to go and recheck the relationship of this document to > the ones listed. So, I haven't done any of that yet, in an attempt to only > have to do it once. > > Specifically, there's skew between the list of documents updated in the top > header and the list in Section 1.1. Evern more annoyingly, the (tools) > HTML version seems to be missing some numbers from the document header, > that are present in the TXT version. (Henrik is going to take a look, per > > https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU > .) > Thanks. > > Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but > there is no "Obsoletes:" header at the top of the document. > > I think nits is right about references (square-bracketed "[RFC6347]") in > the Abstract; we should change those to normal textual (parenthesed > "(RFC 6347)") before IETF LC. > > Some other notes from a quick pass over the main text (though I'll probably > read it again once the above are addressed) follow. > > Section 1 > > It feels a little backwards for a "primary technical reason" to > deprecate a protocol version being that "at least one widely-used > library has plans to drop [it]". > I see what you are saying. The major library dropping it has to do with the number of versions available and supporting them all is cumbersome and could lead to configuration errors on the part of the user. Would you just like "primary" removed or would you prefer more of a change to the text? > > I do appreciate that we give discussion about what we intend > "deprecation" to mean and for whom -- thank you for that! > > Section 2 > > TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant > change to TLS that aims to address threats that have arisen over > the years. Among the changes are a new handshake protocol, a new > key derivation process that uses the HMAC-based Extract-and-Expand > Key Derivation Function (HKDF), and the removal of cipher suites > that use static RSA or DH key exchanges, the CBC mode of > operation, or SHA-1. The list of extensions that can be used with > TLS 1.3 has been reduced considerably. > > While it's true that the initial list of extensions usable with TLS 1.3 > is smaller than the list of extensions usable at TLS 1.2 taken at the > same time, it's also true that the requirements for allocating a new > extension codepoint have been reduced dramatically. So I think I'd say > that this reflects not a desire to reduce the attack surface (as > "measured" by number of extensions) but rather a paradigm shift in how > the protocol works, which leaves some existing functionality > incompatible with the new model. I don't really get a clear sense of > what this current last sentence is trying to say (i.e., whether it's one > of those two descriptions I offered above). > Would you prefer "a significant change", be "a paradigm shift"? If not, could you propose text? > Section 3 > > Similarly, the authentication of the handshake depends on signatures > made using SHA-1 hash or a not stronger concatenation of MD-5 and > SHA-1 hashes, allowing the attacker to impersonate a server when it > is able to break the severely weakened SHA-1 hash. > > My recollection of the WG discussions (which I will go review) is that > we don't really have consensus on the "not stronger" portion of this. > Is that a key component of the document here? (N.B. this is *not* an > invitation to rehash that discussion again! The chairs or I can provide > a summary of points not resolved by previous discussion and points > believed to be adequately agreed upon, which would be a trigger for any > additional discussion that might be needed.) > Since you are already looking at the consensus of this with the chairs, we can wait for your guidance. Best regards, Kathleen > > Thanks for putting this document together (I know that getting all the long > list of references/updates/etc. right is really tedious and frustrating), > and sorry to have been sitting on it for so long. > > -Ben > -- Best regards, Kathleen --000000000000938306059738b016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Just replying = to the parts of the tread that were not responded to already as Stephen wil= l likely be looking at the headers/updates per his message.=C2=A0 Thanks fo= r your careful review.

On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kadu= k <kaduk@mit.edu> wrote:
Hi all,

This is a "preliminary" review only because there's some stra= ngeness
relating to the Updates: (and Obsoletes:) headers, and any changes there would make me need to go and recheck the relationship of this document to the ones listed.=C2=A0 So, I haven't done any of that yet, in an attemp= t to only
have to do it once.

Specifically, there's skew between the list of documents updated in the= top
header and the list in Section 1.1.=C2=A0 Evern more annoyingly, the (tools= )
HTML version seems to be missing some numbers from the document header,
that are present in the TXT version.=C2=A0 (Henrik is going to take a look,= per
https://mailarchive.i= etf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU .)

Thanks.=C2=A0

Additionally, Section 1.1 lists some RFCs that "have been obsoleted&qu= ot;, but
there is no "Obsoletes:" header at the top of the document.

I think nits is right about references (square-bracketed "[RFC6347]&qu= ot;) in
the Abstract; we should change those to normal textual (parenthesed
"(RFC 6347)") before IETF LC.

Some other notes from a quick pass over the main text (though I'll prob= ably
read it again once the above are addressed) follow.

Section 1

It feels a little backwards for a "primary technical reason" to deprecate a protocol version being that "at least one widely-used
library has plans to drop [it]".

I= see what you are saying.=C2=A0 The major library dropping it has to do wit= h the number of versions available and supporting them all is cumbersome an= d could lead to configuration errors on the part of the user.=C2=A0 Would y= ou just like "primary" removed or would you prefer more of a chan= ge to the text?
=C2=A0

I do appreciate that we give discussion about what we intend
"deprecation" to mean and for whom -- thank you for that!

Section 2

=C2=A0 =C2=A0 =C2=A0 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a = significant
=C2=A0 =C2=A0 =C2=A0 change to TLS that aims to address threats that have a= risen over
=C2=A0 =C2=A0 =C2=A0 the years.=C2=A0 Among the changes are a new handshake= protocol, a new
=C2=A0 =C2=A0 =C2=A0 key derivation process that uses the HMAC-based Extrac= t-and-Expand
=C2=A0 =C2=A0 =C2=A0 Key Derivation Function (HKDF), and the removal of cip= her suites
=C2=A0 =C2=A0 =C2=A0 that use static RSA or DH key exchanges, the CBC mode = of
=C2=A0 =C2=A0 =C2=A0 operation, or SHA-1.=C2=A0 The list of extensions that= can be used with
=C2=A0 =C2=A0 =C2=A0 TLS 1.3 has been reduced considerably.

While it's true that the initial list of extensions usable with TLS 1.3=
is smaller than the list of extensions usable at TLS 1.2 taken at the
same time, it's also true that the requirements for allocating a new extension codepoint have been reduced dramatically.=C2=A0 So I think I'= d say
that this reflects not a desire to reduce the attack surface (as
"measured" by number of extensions) but rather a paradigm shift i= n how
the protocol works, which leaves some existing functionality
incompatible with the new model.=C2=A0 I don't really get a clear sense= of
what this current last sentence is trying to say (i.e., whether it's on= e
of those two descriptions I offered above).

=
Would you prefer "a significant change", be "a paradigm= shift"? If not, could you propose text?


=

Section 3

=C2=A0 =C2=A0Similarly, the authentication of the handshake depends on sign= atures
=C2=A0 =C2=A0made using SHA-1 hash or a not stronger concatenation of MD-5 = and
=C2=A0 =C2=A0SHA-1 hashes, allowing the attacker to impersonate a server wh= en it
=C2=A0 =C2=A0is able to break the severely weakened SHA-1 hash.

My recollection of the WG discussions (which I will go review) is that
we don't really have consensus on the "not stronger" portion = of this.
Is that a key component of the document here?=C2=A0 (N.B. this is *not* an<= br> invitation to rehash that discussion again!=C2=A0 The chairs or I can provi= de
a summary of points not resolved by previous discussion and points
believed to be adequately agreed upon, which would be a trigger for any
additional discussion that might be needed.)

Since you are already looking at the consensus of this with the chair= s, we can wait for your guidance.

Best regards,
Kathleen=C2=A0

Thanks for putting this document together (I know that getting all the long=
list of references/updates/etc. right is really tedious and frustrating), and sorry to have been sitting on it for so long.

-Ben


--

Best regards,
Kathleen
--000000000000938306059738b016--