David Benjamin <davidben@chromium.org>

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/