Re: [TLS] Further TLS 1.3 deployment updates
mrex@sap.com (Martin Rex) Fri, 14 December 2018 21:11 UTC
Return-Path: <mrex@sap.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 35638130EA1 for <tls@ietfa.amsl.com>; Fri, 14 Dec 2018 13:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fUhwJ4T2Ivsu for <tls@ietfa.amsl.com>; Fri, 14 Dec 2018 13:11:41 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73241127B4C for <tls@ietf.org>; Fri, 14 Dec 2018 13:11:41 -0800 (PST)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 43GjsR0Xplz106P; Fri, 14 Dec 2018 22:11:39 +0100 (CET)
X-purgate-ID: 152705::1544821899-00000214-9F226957/0/0
X-purgate-size: 951
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 43GjsQ53yZz2ymv; Fri, 14 Dec 2018 22:11:38 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A7533404B; Fri, 14 Dec 2018 22:11:38 +0100 (CET)
In-Reply-To: <20181214185022.GH15561@localhost>
References: <CAF8qwaC1W+U+rQr_0m0h1OJEVrCckqW7-P5_43W1xVf7Rd8TtQ@mail.gmail.com> <20181214185022.GH15561@localhost>
To: Nico Williams <nico@cryptonector.com>
Date: Fri, 14 Dec 2018 22:11:38 +0100
CC: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20181214211138.A7533404B@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LDzFw-5ZIC8zH9JLJsIn_KDITog>
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: Fri, 14 Dec 2018 21:11:44 -0000
Nico Williams <nico@cryptonector.com> wrote: > On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote: >> 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 > > I'm told that OpenSSL accidentally takes the SNI from the initial > connection on resumption if there's no SNI in the resumption. This > seems like a very good workaround for the buggy JDK 11 TLS 1.3 client, > as it has no fingerprinting nor downgrade considerations. Just that this workaround is a no-go for any layered approach to SNI, where server-side processing of SNI is outside of the TLS stack. -Martin
- [TLS] Further TLS 1.3 deployment updates David Benjamin
- Re: [TLS] Further TLS 1.3 deployment updates Hubert Kario
- Re: [TLS] Further TLS 1.3 deployment updates David Benjamin
- Re: [TLS] Further TLS 1.3 deployment updates Hubert Kario
- Re: [TLS] Further TLS 1.3 deployment updates Nico Williams
- Re: [TLS] Further TLS 1.3 deployment updates Adam Langley
- Re: [TLS] Further TLS 1.3 deployment updates Martin Rex
- Re: [TLS] Further TLS 1.3 deployment updates Nico Williams