[TLS] Further TLS 1.3 deployment updates

David Benjamin <davidben@chromium.org> Wed, 12 December 2018 22:21 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 92E2E1312F2 for <tls@ietfa.amsl.com>; Wed, 12 Dec 2018 14:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.958
X-Spam-Status: No, score=-10.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uaKUgG00GLL9 for <tls@ietfa.amsl.com>; Wed, 12 Dec 2018 14:21:56 -0800 (PST)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 553531312EA for <tls@ietf.org>; Wed, 12 Dec 2018 14:21:56 -0800 (PST)
Received: by mail-qk1-x743.google.com with SMTP id w204so22561qka.2 for <tls@ietf.org>; Wed, 12 Dec 2018 14:21:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=JxXP1jYr2einQZ4jsA+4+hwSB4PR8WEXxeFvpRP6MrQ=; b=b/LQ8DMq/jUVoa7M5AMOcsM/YwboByQ87GBFdXXtYwiOSuKHbY5yHniFslxZ6h2ipV tOnCeFfTbl8R6nwjkNmbL/DhjwX55sT+fWRLo02ABeDQZbXAQZt0MQIzZiYeIvt0AXDA kK1CKZjI+TsWV+ssv/8+ond7qvjDIuWeVQiw4=
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; bh=JxXP1jYr2einQZ4jsA+4+hwSB4PR8WEXxeFvpRP6MrQ=; b=BrT+r3YmV5jeeoU7JV1O3lxsC/LlKInNB/m+tdZ/SdO046KC56nGmY6Q2zNc7icjaT EBzhIUjEmEzK++wTKndK4/H0cNyb3VMBXNLO8T9LF+18G5AW9JixeItvj+zKT//qVQ43 8+ng08MMeg+93bwpG0NzusHclGIUnAQA0NNKrdPlAckVnWwKrV8rFRw5Mb1It/eiaWim bkYjekXeCCfrg2K4ohzgy8luR+71ZtW6PIcpmuAUUehY+2p+zdVjKxklP2wgT5LY806y 2VgtmGf9C/+yEiWQ9RZ36IhrelJAdQWClvsYxXE1no6N6WJeEn3datcU3vqYwBVdeL1n k13A==
X-Gm-Message-State: AA+aEWYekdXuY2nLG03ofHcu/lidXcTBKmvAmDGdb15sbnYSQMCxB/2D 4J6gIepnOSZn1aVBTpxfK28FTERKA9Civ+pEsFSs9m/8Dw==
X-Google-Smtp-Source: AFSGD/V+eIeljJW5xuVivacLChQa2cBQUKkR4CRI/S8axwVf65KenVFJXLMsstHUdBGcP+6P2m6fgqGc5rz5chCTy/8=
X-Received: by 2002:a37:c891:: with SMTP id t17mr19327665qkl.31.1544653315115; Wed, 12 Dec 2018 14:21:55 -0800 (PST)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Wed, 12 Dec 2018 16:21:43 -0600
Message-ID: <CAF8qwaC1W+U+rQr_0m0h1OJEVrCckqW7-P5_43W1xVf7Rd8TtQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002697a9057cdaa0a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ>
Subject: [TLS] Further 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: Wed, 12 Dec 2018 22:21:59 -0000

Hi folks,

We have one more update for you all on TLS 1.3 deployment issues. Over the
course of deploying TLS 1.3 to Google servers, we found that JDK 11
unfortunately implemented TLS 1.3 incorrectly. On resumption, it fails to
send the SNI extension. This means that the first connection from a JDK 11
client will work, but subsequent ones fail.

It appears this will be fixed in JDK 11.0.2, which is not yet released. In
the meantime, we have sadly had to detect JDK 11 clients and disable TLS
1.3 for them. This, in turn, raises a problem with the downgrade signal in
ServerHello.random. JDK 11 does implement that downgrade signal, so the
workaround cannot send it. However, the signal is not effective for other
clients unless all TLS 1.2 ServerHellos are marked.

To salvage this for now, we've introduced a second value, generated
    0xed, 0xbf, 0xb4, 0xa8, 0xc2, 0x47, 0x10, 0xff

When Google servers detect JDK 11 and disable TLS 1.3 to work around this
issue, they will use that value in ServerHello.random instead of the
standard 0x44, 0x4f, 0x57, 0x4e, 0x47, 0x52, 0x44, 0x01. Future versions of
Chrome will treat the new value as an alias of the standard one. Other
clients may wish to do the same, but please properly test your TLS 1.3
implementation first.

As JDK 11 is quite recent, we hope this will be relatively short-lived and
that we can remove this workaround and non-standard signal in the future.
Users of JDK 11 should upgrade to 11.0.2 once released to avoid
interoperability issues. In the meantime, they should disable TLS 1.3 by
passing -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 to the java binary.

Finally, as an update to the non-compliant middleboxes we noted previously
<https://www.ietf.org/mail-archive/web/tls/current/msg27066.html>, PAN-OS
8.1.4, PAN-OS 8.0.14, and PAN-OS 7.1.21 appear to now be released. Users of
Cisco and Palo Alto Networks firewall devices should upgrade their
products. We plan to reintroduce enforcement of the downgrade signal
sometime in the next year.