Re: [TLS] Industry Concerns about TLS 1.3

Eric Rescorla <ekr@rtfm.com> Fri, 23 September 2016 20:43 UTC

Return-Path: <ekr@rtfm.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 7A45C12B4FA for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 13:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 UAd7Li67ywdy for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 13:43:56 -0700 (PDT)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 B07B912B13B for <tls@ietf.org>; Fri, 23 Sep 2016 13:43:56 -0700 (PDT)
Received: by mail-yb0-x22a.google.com with SMTP id u125so71764780ybg.3 for <tls@ietf.org>; Fri, 23 Sep 2016 13:43:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.37.80.17 with SMTP id e17mr7407449ybb.105.1474663435883; Fri, 23 Sep 2016 13:43:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Fri, 23 Sep 2016 13:43:15 -0700 (PDT)
In-Reply-To: <DM5PR11MB141926C5806296FFD7252A45F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <CAH8yC8kgYzYXwJ01NkK7WYxD-diponWEQOd+MNHssm+bLHE54w@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com> <72011214.413503.1474650126973@mail.yahoo.com> <e24a06b8d0d04ccc80b9a55d83bf5606@usma1ex-dag1mb1.msg.corp.akamai.com> <DM5PR11MB141926C5806296FFD7252A45F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 23 Sep 2016 13:43:15 -0700
Message-ID: <CABcZeBNCoB6hd-c-x8tzT3k7ZFKs85NS04Fs-_CO+U4YZ-WjQg@mail.gmail.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
Content-Type: multipart/alternative; boundary=001a113eac7c428ab6053d32d600
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/t_Pn_ElVyTzqIxfSs1XoRxxHmkY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
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." <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, 23 Sep 2016 20:43:59 -0000

Andrew,

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
fashion.

-Ekr


On Fri, Sep 23, 2016 at 1:31 PM, BITS Security <
BITSSecurity@fsroundtable.org>; 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 [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich
> Sent: Friday, September 23, 2016 3:08 PM
> To: nalini.elkins@insidethestack.com
> Cc: tls@ietf.org
> 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: richsalz@jabber.at Twitter: RichSalz ______________________________
> _________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>