Re: [TLS] Industry Concerns about TLS 1.3

Eric Rescorla <> Fri, 23 September 2016 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A45C12B4FA for <>; Fri, 23 Sep 2016 13:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 UAd7Li67ywdy for <>; Fri, 23 Sep 2016 13:43:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B07B912B13B for <>; Fri, 23 Sep 2016 13:43:56 -0700 (PDT)
Received: by with SMTP id u125so71764780ybg.3 for <>; Fri, 23 Sep 2016 13:43:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IE5nM9vYxUWZ4WO/d2X4ryo9bATdmP727hn1fNFc0m8=; b=Z+Houtez4OCMc/xFxpK98hZoT9cdm9rcIzFnTxcDwGJSPglgjlS1e9jIHfr/xCEFnK TdtnZfb3ieq9tWOH1I4IUEqyrQ377BS4Sh8bBAfXeTc4LhEMmX/ABEIXFyP4YhBKucuL OCOCPMCHdV4/LBtmvcYtPIs6/zMNvgQDygtspKMSjUaJMD5HgtHEeAINaNEYxJa/xTJY AxC+Ep4NRnA5/r6xwaZFK3zxLwjk0u+zNr36YbZFac021VmgeIBnd79vIhvNlMj1bx4S B/XJmEiybi6vG+dtHAcQYfOjW2e2NfVvV7t0krH02zVAry6WPKQd/tNr3IbLZfZwjfhx U5Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IE5nM9vYxUWZ4WO/d2X4ryo9bATdmP727hn1fNFc0m8=; b=ENoF6uLVSjyq5NmP29ZbjgBFj28W5DjfR2sbg+YxTUiZ1/7pLbw4vfpkgEbIfm0hVI gE5ylUbb0TXrN+x5Bvz3Bcmzu9P9p5UpVbieeSIS0wNGzbNaZAg/OrHVUwZMECVP0W2t 7emzyamuq2AmvDNiQ9CwoxdjWuW4fCSiwnFyhAomjncLVo+d/aGl1GtRHttQ83uPQG9J LvMcgh3eZ1IvsyPL7/2Bv2gH+XTZ/UOsKnklhlefUsGGkXfwXjAchGAfOK8UDdGkk246 qG1sUYFi5oGA/p3wChdJdqurnr0hr5zj2P1d/G//DCysl7EhmTf15KDG4bN2XZrKP2KB qavw==
X-Gm-Message-State: AE9vXwPKyEQMyYpDwlV3uvdtrot0YoZ3R2JfLHURc7Y5OcnS9qXVx2C78bUZ3lUIWyA5rp0usFObOESi6HvsIg==
X-Received: by with SMTP id e17mr7407449ybb.105.1474663435883; Fri, 23 Sep 2016 13:43:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 23 Sep 2016 13:43:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Fri, 23 Sep 2016 13:43:15 -0700
Message-ID: <>
To: BITS Security <>
Content-Type: multipart/alternative; boundary="001a113eac7c428ab6053d32d600"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-Mailman-Version: 2.1.17
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: Fri, 23 Sep 2016 20:43:59 -0000


What would probably be most helpful here would be if you tried to describe
what you think your requirements are in some sort of protocol-neutral


On Fri, Sep 23, 2016 at 1:31 PM, BITS Security <> wrote:

> Rich (et al.) -- I understand where you are coming from but I will poke a
> little bit at this portrayal.
> We are not here hat-in-hand asking for a return to RSA key exchange to the
> proposed standard.  We do however want to raise our concern (and hopefully
> your awareness) of what appears to be an unintended consequence of the move
> to PFS-only choices.
> What is happening from our perspective is choice is being removed and an
> adequate replacement has (seemingly) not been identified.  This lack of
> choice may not affect everyone and every use-case but it will predictably
> affect large, complex, highly regulated enterprises in a serious manner.
> This is a classic case of security requirement being in conflict with a
> different security requirement.
> IETF protocols are run extensively both on the public Internet and within
> private enterprises.  Any decisions made by the TLS Working Group will
> affect both environments, and the needs and requirements of both
> environments should be considered.
> -Andrew
> -----Original Message-----
> From: TLS [] On Behalf Of Salz, Rich
> Sent: Friday, September 23, 2016 3:08 PM
> To:
> Cc:
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
> > It would be very interesting to get the network diagnostic and
> operations people (rather than the architects) of the above companies
> involved in this conversation.
> Nothing has ever stopped them.  Never. Participation is as simple as
> joining a mailing list.  The IETF has been doing SSL and TLS for nearly 20
> years.  It is not a secret.  It was incumbent on them to reach out and get
> involved.
> > Why don't we listen to each other?   I know at IETF, I often hear that
> we don't get enough operators to comment and give feedback.  Well, here you
> have some.  It may be that these companies have problems that are different
> from Google's (just as an example).
> Don't try to equate "listen to each other" with "meet my requirement."
> The message has been stated, very clearly, from individuals, WG members,
> through document editors and WG chairs and up to Security Directors:
> static RSA is not coming back to TLS 1.3 .  Since before the last IETF this
> was the message, consistently.  So perhaps you should answer the question
> first -- why aren't *you* listening? :)
> PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to
> prevent PFS in their existing deployment?  Why won't additional controls to
> prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So
> far all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to
> move to TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs
> in TLS 1.3 too.
> Look, pretty much the entire world is being spied on by national-scale
> adversaries who are recording all traffic for eventual decryption and
> correlation.  *Almost everyone* is having their traffic surveilled. The
> problems of debugging a set of enterprise apps doesn’t amount to a hill of
> beans in that world. It just doesn't. Same for a particular industry's
> regulatory requirements.
> > Isn't our goal to have the best standards possible?   Any organism
> (including the IETF), needs feedback to thrive.
> Oxygen, coke, and cookies too.
> --
> Senior Architect, Akamai Technologies
> IM: Twitter: RichSalz ______________________________
> _________________
> TLS mailing list
> _______________________________________________
> TLS mailing list