Re: [TLS] Update on TLS 1.3 Middlebox Issues

Nick Sullivan <> Sat, 07 October 2017 14:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DF6213320C for <>; Sat, 7 Oct 2017 07:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KcEkeROsivBg for <>; Sat, 7 Oct 2017 07:17:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E53F1331BA for <>; Sat, 7 Oct 2017 07:17:50 -0700 (PDT)
Received: by with SMTP id t69so12818355wmt.2 for <>; Sat, 07 Oct 2017 07:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1QgmwBYqvxOdjueJIpaI3OC6DBvOIG+8gsBs+9EHMCs=; b=RJaJ/YAwhKUlTRtmvFRoCyMpUOj5A+oSqiP+fwTTZY2Rx7iDjm41Hrk58+UaHuonlh LGYcGpgE/oTA3RF5dznukd9Wz8a1LAXHP0T/TN6K7wjlbcB1Yr3UJkOi1HdRzJ+QxQ1p EJbr/hspFEgTCzdVxyljY6hgj1sG0p3VraEVk8p5iKz0+6Mm5qz5NBykP4+6J6fDbWP0 MqQu9IDIZTD7fk+Ayf9fk36PaAYWgAPc/lmAxvgzadw7Em3I6Tg0N8ZCNYCnvWDPIlTT eLgcMhBqPnVu13oixqcTMpQyT6DJiCag0QgCiIMoheLPPQ3j9WM7Ij/N5DQ5Bbuc9v4H QQwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1QgmwBYqvxOdjueJIpaI3OC6DBvOIG+8gsBs+9EHMCs=; b=VUnuraEwiqv5xv2h8Ux/njwsvuPddOdyjSZgEiKLc6l+YYXiJZrnHDVkhuJZbMmty0 5nyNEByB9/cMbEEnilFWATtHHBJOn43+/6JR+ug0SprjJIqtq8QRYX0vGCyIXDZ5rY1h H6h/DisEYNN/Wx3hiczJyKGaxaG4vTZtiOMsVz7Vhq5T0WuFR3SCmnsSF4gA973m1T8E 9b9vhbwIMmt0MzytXQhHz9c6he3GWhHh74YPy/u9Xe8+GgEWRNzny65mgC1XbN5cFZXR gS1zV8lyMUKCHyPTrBuvYB1qBTiwjeIN7Z82cwv9nAicLjczmW8H4Mjo64komHJBZx+O AEqw==
X-Gm-Message-State: AMCzsaU0dvTKPLimg01KqipNxCqfnYTvetmrFY32vZ4Hv2zz0txu20VR pfsKZIlIwpdMLzh1Kot33/PLKjQLxyHSNuj+T0E=
X-Google-Smtp-Source: AOwi7QBRInIBEGRx/42YVwc6Ighx3oc13kYdrdtTvg4TtyHxYQB9DgOWl3bER/7Nr/4b36juDwIEvCe+HPAt38MmNs0=
X-Received: by with SMTP id c72mr4685860wmi.42.1507385869073; Sat, 07 Oct 2017 07:17:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Sat, 07 Oct 2017 14:17:37 +0000
Message-ID: <>
To: Rich Salz <>, Yoav Nir <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a114779fa44016a055af59fb0"
Archived-At: <>
Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Oct 2017 14:17:53 -0000


Let me make a correction to your scenario:. Instead of:
"You’ll need it for Chrome to work with Google."
"You’ll need it for Chrome to work with Google, Facebook, and most of the
10% of Alexa top million sites that are using Cloudflare."

TLS 1.3 (in on draft version or another) is very widely deployed on the
server side. Enabling it by default in a major browser would break enough
of the Internet that both middlebox vendors and enterprises/ISP who use
them will take notice.

The browser vendors will have to do their own calculus around whether or
not the ecosystem benefits of accelerating the deployment of TLS 1.3
compatibility by deploying no-downgrade TLS 1.3 defaults outweigh the
business costs associated with the potential harm to their relationships
with enterprises.

For example, Chrome has a history of making large bets that break a portion
of the internet in order to force ecosystem changes (see SHA-1, SSLv3).
However, these have been projects with gradual changes and long lead times.
Also, the failure rates introduced by such changes were well below 2% of
all connections. Furthermore, these changes typically revolved around
server changes (updating certs, changing configurations) not
software/firmware updates to devices.

I don't want to speak for browser vendors, but history suggests that Option
3) may not be a viable one for browsers with a significant market share.


On Sat, Oct 7, 2017 at 1:33 PM Yoav Nir <>; wrote:

> On 7 Oct 2017, at 4:01, Salz, Rich <>; wrote:
> Thanks very much for the update.
> There is a third option, name the devices which are known to cause
> problems, and move forward with the draft as-is.
> +1.  I like this third option.
> 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
> it's your customers who don't update? Seems you don't have any
> reasonable update system. Call your customers,
> Vendor: Hello customer. We have an update for you that will make TLS 1.3
> work.
> Customer: No way. We’re in the middle of the year-end processing. We’re
> not making any configuration changes until the second week of January.
> Vendor: But it’s a simple fix. It will make things work better. You’ll
> need it for Chrome to work with Google.
> Customer: What part of “not making any configuration changes” was not
> clear to you!?
> _______________________________________________
> TLS mailing list