Subject: [TLS] Additional TLS 1.3 results from Chrome

From: David Benjamin <[email-masked]>
Date: Mon, 18 Dec 2017 14:35:12 -0500

Dear all,

The recent release of Google Chrome 63 enabled (effectively) TLS 1.3
draft 22 for 95% of stable channel users who updated. (Our previous
results were on our beta channel.) While, in the past, we have
demurred[1] from providing details about problematic products we now
plan to alter that stance. It is late in the game for TLS 1.3 and we
have likely exhausted the scope of wire-format tricks to improve
deployment viability (although there is one more helpful tweak below).
Since other vendors will also be seriously deploying TLS 1.3 soon, we
want to share all that we have learned from Chrome.

We note, however, that even being included in a stable release of
Google Chrome doesn’t provide a full picture of any issues. For
example, enterprise customers may choose not to release any new
versions of software into their organisations in the run-up to
Christmas and New Year’s. Also, we are aware that only a tiny fraction
of issues result in user reports.

This experiment in Chrome 63 will end on 2017-12-19, hopefully
ensuring a quiet Christmas.

BSAFE

The web interface on some Canon printers breaks with 1.3-capable
ClientHello messages. We have purchased one and confirmed this with a
PIXMA MX492. User reports suggest that it also affects PIXMA MG3650
and MX495 models. It potentially affects a wide range of Canon
printers.

These printers use the RSA BSAFE library to implement TLS and this
library implements the extended_random extension and assigns it number
40. This collides with the key_share extension and causes 1.3-capable
handshakes to fail.

We understand that this has been fixed in BSAFE ≥ 4.1, but older
versions still exist in the world. Canon is aware of this and is
planning on issuing firmware updates, although the uptake of firmware
for printers is typically poor.

However, since extension numbers are essentially infinite, this WG may
consider renumbering key_share to avoid the issue.

Dymo (the label-printer manufacturer) is experiencing a similar[2]
issue with some of their software. We have not been able to reproduce
but one guess is that they are also using BSAFE.

(Lastly, we note that in the paper "On the Practical Exploitability of
Dual EC in TLS Implementations", the authors remarked that they had no
evidence that a version of BSAFE with extended_random support ever
shipped. TLS 1.3 appears to have tripped over it.)

Cisco Firepower

After receiving a report of issues with a Cisco “Firepower” device we
purchased one to try and reproduce the issue.

We found that Firepower middleboxes in "Decrypt - Resign" mode
terminate TLS connections, but do not send a compliant ClientHello:
They modify the original ClientHello to remove unknown ciphersuites,
EMS, and NPN, but incorrectly forward most other fields from the
original ClientHello, including unknown extensions (supported_versions
and key_shares), and the client random. This breaks TLS 1.3 servers.
Additionally, these devices forward the server random rather than
generating their own (which will break when deploying the TLS 1.3
anti-downgrade feature), and forward unknown signature algorithms
(which will break when deploying, e.g., Ed25519).

Disabling "Decrypt - Resign" mode appears to work around this issue.
To fix this mode, these devices will need to stop forwarding unknown
extensions and generate their own random values.

We have provided Cisco with this information.

Avast Antivirus

We have received one report that Avast’s HTTPS scanning feature breaks
connections that negotiate TLS 1.3. The user reported that disabling
HTTPS scanning solved the issue. We were not able to reproduce so this
might only occur with older versions of Avast.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg24535.html
[2] http://developers.dymo.com/2017/12/12/err_ssl_version_interference-in-chrome-63-using-the-js-sdk/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Dec 2017 13:03:52 -0800

> consider renumbering key_share to avoid the issue.

I think this would be fine, but not imperative.

-Ekr

> [2] http://developers.dymo.com/2017/12/12/err_ssl_version_
> interference-in-chrome-63-using-the-js-sdk/
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Tanja Lange <[email-masked]>
Date: Tue, 19 Dec 2017 00:08:06 +0100

Dear David, dear all,
> 40. This collides with the key_share extension and causes 1.3-capable
[..]
> shipped. TLS 1.3 appears to have tripped over it.)
Wow, thanks for finding this, it was really baffling us.

All the best
	Tanja

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Dec 2017 01:59:34 +0000

> I think this would be fine, but not imperative.

I think it would almost be hypocritical if we did not do it.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Dec 2017 13:07:02 +0000

Hiya,

> I think it would almost be hypocritical if we did not do it.

I'm not sure I agree renumbering is the right reaction,
though I don't object to that. This could be a case where
it's overall better that those specific devices suffer
breakage, and hopefully then do get firmware updated to
support TLS1.3 or TLS-without-extended-random-or-dual-ec
at some point.

WRT extended-random, it seems like the IETF process did
work, in that we dropped the work. However, it may also
be the case that the attacker's process (if one assumes
that somewhere in the background (*) there was an attacker
who wanted dual-ec attacks to be more efficient) also
worked to at least some extent in that they got that to
be deployed in some places, presumably at least partly
based on the existence of the (then expired?) draft.

I wonder if that argues for some kind of "dropped as a
very bad idea" tombstone draft (or even RFC) for such
cases? I can imagine that the IETF or TLS WG could do
that, but I'm not sure if it'd have helped the developers
of bsafe or those printers avoid the problem if such a
thing had existed. In the case of extended-random, it
is now clear that it is a very bad idea, even if that
wasn't the case when the WG chose to not proceed with
the work, so such a tombstone draft or RFC could be
easily done and could possibly be useful. (I'm about
half-convinced of that;-)

One reason to think about this is that we have some
more-current bad-idea drafts (e.g. draft-green) that
we know are dead, but folks not involved in the WG might
not be aware of that, so it could be good if those
were somewhat more officially put to rest than just
sitting forever as expired I-Ds. It'd be a fine thing
if the authors of such drafts did that themselves of
course, but if not, I'd volunteer to help:-)

Cheers,
S.

(*) To be clear, I am not at all saying the authors of
the extended-random draft were part of any attack. If
I were the bad actor in such a case, I'd ensure the
names that were public weren't in on the plan.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Dec 2017 13:56:50 +0000

“dropped as a bad idea” is an interesting end-state.  Also “on hold for now” (which is how I want to see the TLS-breaking proposals).

Having more I-D workflow options seems like something the IESG should take up.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Dec 2017 14:19:41 +0000

Hiya,

On 19/12/17 13:56, Salz, Rich wrote:
> “dropped as a bad idea” is an interesting end-state.  Also “on hold
> for now” (which is how I want to see the TLS-breaking proposals).
> 

Well, TBH I doubt it'd be best done from the IESG down.

If some WG wanted to pursue this kind of thing, I'd say
it'd be much better done by the WG and then the IESG
could get to decide what they think if/when such a draft
is ever put forward by the WG for publication as an RFC.

And for most WGs, there's little danger in expired I-Ds
hanging about unchanged. For TLS, as we've seen in this
case, there might be a downside to the expired I-D not
containing text saying: "Don't do this! Really. And
<here's> why." :-)

As an aside, I'd say it'd be better to not think of
this as a retraction, but more as a case of ensuring
that the public record, as seen in the I-D repository,
better reflects the WG consensus, for the few cases
where there would be a concrete reason to not want
people to write or deploy code implementing the draft
concerned.

For a WG draft, the WG itself can always decide that
the right thing to happen is to publish a tombstone
draft, so that could be handled easily enough.

For a draft that's proposed for WG adoption, or that's
discussed but not adopted, it might get complicated, if
the authors don't agree that WG non-adoption is a good
reason to put out a tombstone. (We'd likely need the WG
to adopt the draft solely to put out the tombstone,
which'd be a bit weird.)

So as I said, I'm about half-convinced:-)

Cheers,
S.

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 19 Dec 2017 15:08:30 +0000

> I'm not sure I agree renumbering is the right reaction, though I don't 
> object to
> that. This could be a case where it's overall better that those specific 
> devices
> suffer breakage, and hopefully then do get firmware updated to support
> TLS1.3 or TLS-without-extended-random-or-dual-ec
> at some point.

It's never better to break large numbers of things, if it can be avoided at 
low
cost.  The reaction isn't going to be "TLS 1.3 broke my printer, it's time to
upgrade my firmware.", it's going to be "TLS 1.3 broke my printer, which was
working perfectly fine.  TLS 1.3 is bad.  I wonder what else they got wrong.
People shouldn't use TLS 1.3."

-Tim

---

From: Adam Langley <[email-masked]>
Date: Tue, 19 Dec 2017 08:28:38 -0800

> support TLS1.3 or TLS-without-extended-random-or-dual-ec

I think we would like to avoid deliberately breaking these devices with TLS
1.3. (I think TLS 1.3 has been subject to enough friction already.)

If key_share is renumbered, then presumably extension 40 would be reserved
by IANA. Thus other implementations could send extension 40 if they wish
not to interoperate with extended_random-supporting peers.

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Dec 2017 07:01:30 -0800

PR:
https://github.com/tlswg/tls13-spec/pull/1128

I'll merge this next week, barring strong objection.

-Ekr

On Tue, Dec 19, 2017 at 8:28 AM, Adam Langley <[email-masked]>
wrote:

> On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell <
> [email-masked]> wrote:
>
> I think we would like to avoid deliberately breaking these devices with
> TLS 1.3. (I think TLS 1.3 has been subject to enough friction already.)
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 27 Dec 2017 20:35:27 +0200

> I'll merge this next week, barring strong objection.

You might want to rebase that and renumber to #51, now that extension
#50 is used for certificate signature algorithms.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Dec 2017 10:45:40 -0800

Good catch. Thanks.

-Ekr

---

From: David Wong <[email-masked]>
Date: Thu, 28 Dec 2017 09:54:28 +0100

> I think we would like to avoid deliberately breaking these devices with TLS 1.3. (I think TLS 1.3 has been subject to enough friction already.)

I'm not sure I can agree with fixing TLS 1.3 so that it can work with
potentially backdoored devices. Isn't it the kind of friction we would
want?

David