Subject: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Nov 2019 11:53:25 -0800

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

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Nov 2019 20:07:09 +0000

Hiya,

On 11/11/2019 19:53, Benjamin Kaduk wrote:
> header and the list in Section 1.1. 

Ah, the fun:-)

Will take a look when I get some time, but might be whilst
in or en-route to Singapore. If you've any examples you
noted that might help,

Cheers,
S.

---

From: "Kaduk, Ben" <[email-masked]>
Date: Mon, 11 Nov 2019 20:27:09 +0000

The one concrete one that I remember (and can't attribute to the HTMLized version dropping stuff) is RFC 7030 only in the header.

I guess we can check what we want to do to DTLS as well, as RFC 6347 is listed as Updates:-ed but that's the DTLS 1.2 spec.  (6347 itself confusingly claims in the body text to "update DTLS 1.0 to work with TLS 1.2" but has an "Obsoletes: 4347" header.)  I don't see what specifically we update in 6347.

-Ben

P.S. sorry for top-post; Outlook's quoting options are "bad" and "worse"

On 11/11/19, 12:07, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

    Ah, the fun:-)

    Cheers,
    S.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 11 Nov 2019 14:42:56 -0800

On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben <[email-masked]> wrote:

> The one concrete one that I remember (and can't attribute to the HTMLized
> version dropping stuff) is RFC 7030 only in the header.
>
> I guess we can check what we want to do to DTLS as well, as RFC 6347 is
> listed as Updates:-ed but that's the DTLS 1.2 spec.  (6347 itself
> confusingly claims in the body text to "update DTLS 1.0 to work with TLS
> 1.2" but has an "Obsoletes: 4347" header.)  I don't see what specifically
> we update in 6347.
>

 I think the text in question is the last paragraph of RFC 6347's
Introduction:

"Implementations that speak both DTLS 1.2 and DTLS 1.0 can
   interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of
   course), just as TLS 1.2 implementations can interoperate with
   previous versions of TLS (see Appendix E.1 of [TLS12] for details),
   with the exception that there is no DTLS version of SSLv2 or SSLv3,
   so backward compatibility issues for those protocols do not apply."

This draft says "don't interoperate" in this situation.

thanks,
Rob

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 12 Nov 2019 09:58:48 +1100

Since Rob quoted this:

>  with the exception that there is no DTLS version of SSLv2 or SSLv3,

...also on this list is TLS 1.0.  DTLS 1.0 is TLS 1.1.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 11 Nov 2019 19:04:12 -0800

On Mon, Nov 11, 2019 at 2:59 PM Martin Thomson <[email-masked]> wrote:

> ....also on this list is TLS 1.0.  DTLS 1.0 is TLS 1.1.
>

That passage in RFC 6347 does indeed seem incomplete. However, I think the
general point stands, because draft-ietf-tls-oldversions-deprecate-05
deprecates TLS 1.1.*

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Nov 2019 07:58:02 -0800

> This draft says "don't interoperate" in this situation.

I don't typically get too exercised about what appears in these metadata
headers, but I don't actually think this updates 6347. The statement there
is still true, we just tell you not to do it.

-Ekr

> thanks,
> Rob
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Nov 2019 07:58:14 -0800

> ....also on this list is TLS 1.0.  DTLS 1.0 is TLS 1.1.

Yes, but that's presumably an erratum.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 12 Nov 2019 09:56:46 -0800

On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla <[email-masked]> wrote:

>>> The one concrete one that I remember (and can't attribute to the
>>> HTMLized version dropping stuff) is RFC 7030 only in the header.
>>>

Well... I think the clearest definition of "updates" is in RFC 2223:

https://tools.ietf.org/html/rfc2223#section-12

"... e.g., an addendum, or separate, extra information that is to be added
to the original document."

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Nov 2019 10:23:46 -0800

> to the original document."

Yes, and I don't think that this does that.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 12 Nov 2019 10:46:35 -0800

On Tue, Nov 12, 2019 at 10:24 AM Eric Rescorla <[email-masked]> wrote:

>>>>> I guess we can check what we want to do to DTLS as well, as RFC 6347
>>>>> is listed as Updates:-ed but that's the DTLS 1.2 spec.  (6347 itself
>> "... e.g., an addendum, or separate, extra information that is to be
>> added to the original document."
>>
>

OK. I agree with what you wrote: "The statement there is still true, we
just tell you not to do it."

That seems like new information a reader of RFC 6347 should be made aware
of.

thanks,
Rob

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 13 Nov 2019 06:29:44 -0500

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.

> https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU

Thanks.

> 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?

> of those two descriptions I offered above).

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

> 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

-- 

Best regards,
Kathleen

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 14 Nov 2019 12:53:11 -0800

> like "primary" removed or would you prefer more of a change to the text?

The main reason I raised it is that it doesn't feel like a *technical* reason;
it's done for expediency and perhaps with a bit of politics, but there's nothing
technical about the protocol involved.

> Would you prefer "a significant change", be "a paradigm shift"? If not,

I'm trying to say that the reduced size of the list of extensions is just
a side effect, not an end in its own right.  
But, I seem to have missed that this paragraph is part of a quotation from a
NIST document, so I don't get to wordsmith it :)

> can wait for your guidance.

Okay.  That might not happen until after Singapore, though.

-Ben