[TLS] Yet more TLS 1.3 deployment updates

Adam Langley <agl@imperialviolet.org> Tue, 22 January 2019 19:06 UTC

Return-Path: <alangley@gmail.com>
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 E20B912875B for <tls@ietfa.amsl.com>; Tue, 22 Jan 2019 11:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 VBdoaRNj3FbP for <tls@ietfa.amsl.com>; Tue, 22 Jan 2019 11:06:48 -0800 (PST)
Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) (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 4E4DE12785F for <tls@ietf.org>; Tue, 22 Jan 2019 11:06:48 -0800 (PST)
Received: by mail-qt1-f194.google.com with SMTP id y20so28820941qtm.13 for <tls@ietf.org>; Tue, 22 Jan 2019 11:06:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=SdaBXTJHE8b8axLan65+7E9CfNX7R9nttthLLiqzSCU=; b=Qi0CcOwgmhl3Zbvm1quov+Lt9z7HfaRoldtq+PdBLMmcEBlrAejFrK76L0UIyAKoOX twiscEl6O+/G9sC47gh9zZtHAHYd3Lq89GDJKJ/4IJqMVfqRSpWG4yInp3QFqWN0dLb8 ednUbNJAAiiD4nDc0tNMk2xsJXJjG3ZM+mrB+5J1Tn2pIqI0WLe3ZwZkM+UDM/QKQITt 8Pb0xOIaDMgL0VJ8SARVbLtxLWk/LuFivL+IYL1MCd1ijfyllUDSuq8/k0V3IxR6hccK wqjvbUwdAakMvVpwjzCDdaX/PEPOdwK+KehQ2f9Qr/adkAFpzcgme5jmujgRgDs0q4zD nlWg==
X-Gm-Message-State: AJcUukdeKWnYpkwUTt816iGV2TaHq8cBVKmTCBF2hyoZEiiujHLBBoB4 0osW3U9Qo74On8Ih46N1LSyuNTQ8uXtpCTU/mC2tHGR1
X-Google-Smtp-Source: ALg8bN4XUYjfZ9ToWLbjejiB/1KIaSPxtV1kjeuzwA00IGZ1SK6Kw1sxG9kLepVUVJZMY+bLMYhELhw1eSi9vwoxh8Q=
X-Received: by 2002:ac8:7201:: with SMTP id a1mr32608897qtp.291.1548184006609; Tue, 22 Jan 2019 11:06:46 -0800 (PST)
MIME-Version: 1.0
From: Adam Langley <agl@imperialviolet.org>
Date: Tue, 22 Jan 2019 11:06:35 -0800
Message-ID: <CAMfhd9Ucz-+bXhOROenwJTnpk3ex1oO-wL8drhtTf7UFcWipbg@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Aw1WY5gBAifAZXowgx5Ym82RIKI>
Subject: [TLS] Yet more TLS 1.3 deployment updates
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2019 19:06:51 -0000

(This is another installment of our experiences with deploying the
RFC-final TLS 1.3—previous messages: [1][2]. We share these with the
community to hopefully avoid other people hitting the same issues.)

In the last update, David reported our experience with a bug[3] in
Java 11's TLS 1.3 implementation. We can confirm that this was fixed
in 11.0.2. However, since then another issue[4] has come to our
attention[8], the fix for which is not in any released version of Java
11. Additionally, we have found a third issue by code inspection which
we'll report on the Java bugtracker.

As such, we continue to fingerprint Java 11 clients on the server and
deny them TLS 1.3. This undercuts TLS 1.3's anti-downgrade measures
and we continue to send a special nonce suffix in that case[2].

Last week we tried sending KeyUpdate messages in Google Chrome, which
went poorly. Several, major OpenSSL-using applications block TLS 1.2
(and prior) renegotiation by installing a callback with OpenSSL and
watching for SSL_CB_HANDSHAKE_START events after the handshake has
completed. Such events are assumed to be renegotiation attempts by a
client and cause the connection to be dropped.

However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3
post-handshake messages are received[5], including KeyUpdate. This
causes KeyUpdate messages to break with, at least, HAProxy, and with
NGINX prior to this commit[6]. (There may well be more, but that level
of breakage was enough to drown any other signal.)

Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages
per connection[7]. Therefore clients that send periodic KeyUpdates
based on elapsed time or transmitted bytes will eventually hit that
limit, which is fatal to the connection.

Therefore KeyUpdate messages are not currently viable on the web, at
least when client initiated.

[1] https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE
[2] https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ
[3] https://bugs.openjdk.java.net/browse/JDK-8211806
[4] https://bugs.openjdk.java.net/browse/JDK-8213202
[5] https://github.com/openssl/openssl/issues/8069
[6] https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc39dde5ee/nginx/src/event/ngx_event_openssl.c
[7] https://github.com/openssl/openssl/issues/8068
[8] https://twitter.com/__subodh/status/1085642001595265024


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org