Subject: [TLS] New version intolerance caused by draft-26 supported_versions change?

From: Joseph Birr-Pixton <[email-masked]>
Date: Mon, 9 Apr 2018 22:16:06 +0100

Hello,

PR#1163 in draft-26 seems to have broken interop with previous drafts
with a variety of deployed implementations. draft-26 and later clients
fail with a protocol_version alert.

Affected Internet servers include:

cloudflare.com: offers draft-23, intolerant to draft-26
www.apple.com: seemingly unwilling to negotiate any draft, but
intolerant anyway(?)
www.microsoft.com: same
google.com: same

https://jbp.io/assets/tls13-logs/cloudflare.broken.txt
https://jbp.io/assets/tls13-logs/apple.broken.txt
https://jbp.io/assets/tls13-logs/microsoft.broken.txt
https://jbp.io/assets/tls13-logs/google.broken.txt

In all these cases, offering TLS1.2 in supported_versions (ie, the
pre-draft-26 behaviour) works, and TLS1.2 is negotiated:

https://jbp.io/assets/tls13-logs/cloudflare.works.txt
https://jbp.io/assets/tls13-logs/apple.works.txt
https://jbp.io/assets/tls13-logs/microsoft.works.txt
https://jbp.io/assets/tls13-logs/google.works.txt

Corroboration appreciated.  It's totally possible I'm doing something stupid :)

Thanks,
Joe

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Apr 2018 16:29:12 -0500

> Corroboration appreciated.  It's totally possible I'm doing something stupid :)

It is not expected for draft-NN to interoperate with draft-YY, but implementations
thereof that also support TLS 1.2 should be able to negotiate TLS 1.2.
So depending on what you mean by "intolerant", there may be nothing to see here.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Apr 2018 21:29:44 +0000

Your results are not really very surprising.

Different folks are at different drafts, and "everyone" is waiting for the final RFC to be published and upgrade then.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Apr 2018 14:29:38 -0700

> pre-draft-26 behaviour) works, and TLS1.2 is negotiated:

You're just sending supported_versions = {0x7f1a}, but that's not
correct. You need to send {0x7f1a, 0x0303}:

"

   The "supported_versions" extension is used by the client to indicate
   which versions of TLS it supports and by the server to indicate which
   version it is using.  The extension contains a list of supported
   versions in preference order, with the most preferred version first.
   Implementations of this specification MUST send this extension in the
   ClientHello containing all versions of TLS which they are prepared to
   negotiate (for this specification, that means minimally 0x0304, but
   if previous versions of TLS are allowed to be negotiated, they MUST
   be present as well).

"

So what's happening here is the any server which knows about TLS 1.3
(supported_versions)
is getting a version mismatch.

PR#1163 was just about what the server sends.

-Ekr

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

---

From: Joseph Birr-Pixton <[email-masked]>
Date: Mon, 9 Apr 2018 22:35:57 +0100

> PR#1163 was just about what the server sends.

Aha. This is the bit I missed. I had interpreted "you can't negotiate
pre-TLS 1.3 with supported_versions" applied to both ends.

Thanks!
Joe