Re: [TLS] Further TLS 1.3 deployment updates

Adam Langley <agl@imperialviolet.org> Fri, 14 December 2018 19:25 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 036671312A7 for <tls@ietfa.amsl.com>; Fri, 14 Dec 2018 11:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 BkYkxh68v5Cm for <tls@ietfa.amsl.com>; Fri, 14 Dec 2018 11:25:24 -0800 (PST)
Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (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 67C481312A6 for <tls@ietf.org>; Fri, 14 Dec 2018 11:25:24 -0800 (PST)
Received: by mail-pg1-f178.google.com with SMTP id z10so3118287pgp.7 for <tls@ietf.org>; Fri, 14 Dec 2018 11:25:24 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=giIZzANnNOm5BqejXwH2cBXeFGXuht9Rkh1fKCld018=; b=THD9uoj8DgNTWxIEAyZPflos7E4WqkSKtUcPQBlfkVjvZqkEKm/G1EEgDTSdLXCVYq ZvwrphUOTvkkZuz7Kwna3AsRzyNd+JRroGKz0NtL+bhm0S2TBnnTu45zmrVr+m8PHJhf 5Yk6bwfmFozhdvUQs3nTAlfjGcZww3t71rh5IMpNELnKB5DGw5vANCKaE44FjJmy6l4c 1n2zBQPLTtD8pkSHMbpKphMAWg79HsxuSkI4VMMkwOxe2osHrNReNpYmSwTLN7XzXUYA c8rC3D3DQrE3IPtYgVDZiOLv0mYX6BZgqkbD2Itu7VekWfMH1Fd7OJzMO9C/yMMbr1XI M2nA==
X-Gm-Message-State: AA+aEWbPG7xgjdH/VVOo1RjaOqbgvnoJXsVxW7uCp573R1BSzwQVhzc0 OJZ2NKX1gOc+jzLE/2O/H50dVPUEHawCq1FlJ30=
X-Google-Smtp-Source: AFSGD/WyQ9BzVFL9pVHLD2xKB1XQ6d2eWe1eTognAOOpXVVi4kcC9QKllYhoNLpK3lzdS51mDGJ932xnjAWcg/aylaI=
X-Received: by 2002:a63:f201:: with SMTP id v1mr3536265pgh.232.1544815523537; Fri, 14 Dec 2018 11:25:23 -0800 (PST)
MIME-Version: 1.0
References: <CAF8qwaC1W+U+rQr_0m0h1OJEVrCckqW7-P5_43W1xVf7Rd8TtQ@mail.gmail.com> <20181214185022.GH15561@localhost>
In-Reply-To: <20181214185022.GH15561@localhost>
From: Adam Langley <agl@imperialviolet.org>
Date: Fri, 14 Dec 2018 11:25:12 -0800
Message-ID: <CAMfhd9VEY7Detb6H+mCcnpfWGh7nQky=XSQ-NsK8-cRDaiQFRg@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008628e1057d006491"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/R7xjpNLe3V3mUPsISL3Fn894OCU>
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 19:25:26 -0000

On Fri, Dec 14, 2018 at 10:50 AM Nico Williams <nico@cryptonector.com>;
wrote:

> If the server rejects resumption I guess the client would still fail,
> but this is much better than failing at 100% of all resumptions and
> better than adding fingerprinting and downgrades.
>

In order for TLS 1.3 deployment to be viable the failure rate needs to be
negligible. It's not feasible to construct things such that moving traffic
across session caching domains causes a wave of handshake failures.
Additionally, if we were to wait for these versions of Java to die out in
the ecosystem, we risk other buggy clients getting established in the mean
time. We are painfully aware that limiting our server-side deployment
allowed this bug to become established and, while we did it to ease
middlebox issues, it may have been a mistake.


Cheers

AGL

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