Re: [TLS] Further TLS 1.3 deployment updates

David Benjamin <davidben@chromium.org> Thu, 13 December 2018 17:04 UTC

Return-Path: <davidben@google.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 6F2D7130DEF for <tls@ietfa.amsl.com>; Thu, 13 Dec 2018 09:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.959
X-Spam-Level:
X-Spam-Status: No, score=-10.959 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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6aS7grVLnMi for <tls@ietfa.amsl.com>; Thu, 13 Dec 2018 09:04:26 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 2C601130DED for <tls@ietf.org>; Thu, 13 Dec 2018 09:04:26 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id g125so1323562qke.4 for <tls@ietf.org>; Thu, 13 Dec 2018 09:04:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HqjQm+dkQqp/fTIohU4zYFNKvhqjnfYx3MxoH/hk3TI=; b=cqV5Ph1Egq/o2+BP2U1Ne0S+EdAMh0hgar/YKk5QsnKBjnEU0PDNpkHeeemxyQPMq5 NSsrdmNZdVzZRcW0V6C3sO+UF9yaKmYCyDVu+KYot3HfLzohtkPZkO4iuPOpUQJRWK/Q ErBw7C5eWqPAeLWlijirq4GGCuE4cqAgdR3S4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HqjQm+dkQqp/fTIohU4zYFNKvhqjnfYx3MxoH/hk3TI=; b=sfm/eNrBubBSRL8lhS/9giHCtWctv49552swB+A4yUp17DjC9w3P9qLGIbMiQEXafs AG01YZnIQMOOiDuc9/g8l7Zwt78iZGLn5vTHyQnGH6xO9ZtxSpiSZCzebWLYTPnOsCih OJOQXTPcGPYGfTvWByEcgC7fglbO4t29eE3lTmk1XlQMcjxhNEDWtrewLK79yPyJeVFS 9Ioa47mtsBXAKrtuesio1ugKuZOMbfqZay1Fa8x2zewuDrvsqG3rm5unmF9KRBks/YLm ZjMDxgZocRyOu8kyNCvZWkRFkVS93NYH0ILHu0+OTguBk3Qm8yw3H6yIuGooR8i7+i9n HnpA==
X-Gm-Message-State: AA+aEWaG/Dfi+Q5nFUX6fosu9Qpl48Ry8TCYiFHNvmPN7606EYG1bedB DARkCDrzA1JeToXxpqo8vvGV3PIKlaSzxNL0QgEvkkFnnQ==
X-Google-Smtp-Source: AFSGD/UWBO+omn52tYa8pv3oRjoQCZNvdaIq1Cr3BJEvxbA6Et7amXm4CRquXsylI/JuTXsIl2CaLTCsAyNaomgYHnE=
X-Received: by 2002:a37:688c:: with SMTP id d134mr23049223qkc.57.1544720665173; Thu, 13 Dec 2018 09:04:25 -0800 (PST)
MIME-Version: 1.0
References: <CAF8qwaC1W+U+rQr_0m0h1OJEVrCckqW7-P5_43W1xVf7Rd8TtQ@mail.gmail.com> <1588490.iHGf2W1UT2@pintsize.usersys.redhat.com>
In-Reply-To: <1588490.iHGf2W1UT2@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 13 Dec 2018 11:04:12 -0600
Message-ID: <CAF8qwaACQncPCSJBdVrCiBAy904AuS=GScdrYUDYkxe8WuA4DA@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000086ffa3057cea4e8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GJC-wop3WHkPQ094kToR7anSnGI>
Subject: Re: [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: Thu, 13 Dec 2018 17:04:29 -0000

On Thu, Dec 13, 2018 at 10:54 AM Hubert Kario <hkario@redhat.com>; wrote:

> On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote:
> > 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.
> > https://bugs.openjdk.java.net/browse/JDK-8211806
> >
> > 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
> > randomly:
> >     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.
>
> there is now a server test script in tlsfuzzer for standard downgrade
> sentinel:
>
> https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-downgrade-protection.py
>
> example of usage: https://github.com/tomato42/tlsfuzzer/pull/479/files


That's not the problematic direction here. If someone ships a TLS 1.3
*client* which enforces the downgrade sentinel, it is important that the
TLS 1.3 implementation not contain show-stopping bugs. The reason JDK 11's
problem impacts the downgrade sentinel is because JDK 11 lacks a working
client TLS 1.3 implementation, but it insists it has one by way of
enforcing the signal on the client.

David