Re: [TLS] Industry Concerns about TLS 1.3

Eric Rescorla <ekr@rtfm.com> Fri, 23 September 2016 17:38 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 6830D12B0AD for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 10:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 Va-PawKOzRkC for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 10:38:25 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 B84D412B0B2 for <tls@ietf.org>; Fri, 23 Sep 2016 10:38:24 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id u82so118547127ywc.2 for <tls@ietf.org>; Fri, 23 Sep 2016 10:38:24 -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=v3ZibkW5ctXsDsm32VJW/8m2cQ6nuVWWbVQuHcSqgvM=; b=DKfESQ1H1IQ2QdiqkX8hOflkSjNcGBEnN921qg7ELSFl8Y+LRRhYWfBsDDq68D/hnQ eqllLH/DycO2cvXwqg2CaGLCfXRTx2PnywAJUNYWxrmumfTbheL74O1evTneyNlmMxha 2GMXcba9VMvsEjpRYX8H70l/81kvy4qi9O6X9QmKtTDCAz2BaR+1qyP2fcJiUr5dRzXy rCXMxxJymF4oZgLEXQrNF6+SuIqCBHUEGUlmanpuHq5t0YA4hv0IcQU80ZxeMNNVRRyT L9F/3612yj/kz+hOwc+Ze22g+x6ORihm1zSCKxePqiaDUYOfLSy0mujVSyYRNtI27J6e Q1eg==
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=v3ZibkW5ctXsDsm32VJW/8m2cQ6nuVWWbVQuHcSqgvM=; b=Pj7lS/FZ/QmOMhh5ym6IC5USTkgVQ47LraneAvbahvmAQSy1ScMKww2EHSYaF3hsQo xIvouzDCiS0XuZu6cN6Mi6Uzpi8iW+7oqSr8QZ9lIqLjrstMcFaHgsnlrWdTiyoh5p6s 0taCVhtRA0uzkWpoKxsoZ6BpMt9gf3cCphu7mn5QUeIMA+MLH6FSItFXWt3IfmQP3HJq lpW/jujBYi3F9lMhVDzqXhz5cxASp4JMskGFh7SBnd5igtdTnvVNngZ5Qh4GXXHAChbz 1mGfOfArqVnEfFaxpN3Sx9qzNezkSgpEell31L5H+4i+Sfy3Z4+OjyxW11AOt/jXh4hW u9qw==
X-Gm-Message-State: AE9vXwMnTH8CHraZmncEj2fhXHJ2/nJ2w8E+e/2HVw5ddjEai01BFSh9bbP29oJ2V1IW7TWRmNZpWMOojiQRRg==
X-Received: by 10.129.83.193 with SMTP id h184mr6834315ywb.52.1474652303936; Fri, 23 Sep 2016 10:38:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Fri, 23 Sep 2016 10:37:43 -0700 (PDT)
In-Reply-To: <4FC37E442D05A748896589E468752CAA0DBC6CAC@PWN401EA120.ent.corp.bcbsm.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> <4FC37E442D05A748896589E468752CAA0DBC6CAC@PWN401EA120.ent.corp.bcbsm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 23 Sep 2016 10:37:43 -0700
Message-ID: <CABcZeBOxKzYx9tVrThd69nqU9gfxdAcE5ug2UWD5n3QqoLbTpQ@mail.gmail.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Content-Type: multipart/alternative; boundary=001a114d6f1cbe82e9053d303e84
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OMzSBsJvoLb-8JQFkzCn0ePXIt8>
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 17:38:27 -0000

A few observations:

+ TLS 1.3 is designed around the assumption that we are doing DH-style
  key establishment. There are good reasons for this, both in terms of
  protocol simplicity and in terms of establishing a baseline of
  strong modes (PFS, compatibility with standard uses of EC,
  etc.). Re-adding a key transport mode like TLS 1.2 static RSA would
  be extremely disruptive, even if it weren't being raised so late in
  the process. It's certainly not just a matter of changing some
  RFC 2119 language forbidding static RSA.

+ As several people have observed, there are several potential ways to
  build an equivalent capability that's compatible with TLS 1.3 as it
  currently is designed (see for instance Hugo Krawczyk's email [0])
  They would of course require a different interface between the
  monitoring appliance and the server (i.e., you would need to export
  a different kind of key and use it somewhat differently on the
  monitoring system), but it's not significantly less efficient.

-Ekr

[0] As well as his caveat about analysis being needed here.


On Fri, Sep 23, 2016 at 9:49 AM, Ackermann, Michael <MAckermann@bcbsm.com>;
wrote:

> Without re stating the original message from the bank coalition,  which
> states this better than I could,   the client and MITM solutions are not
> practical in many situations.    Also they do not provide the scope, depth
> or detail that is utilized with today's solutions.
>
> -----Original Message-----
> From: Watson Ladd [mailto:watsonbladd@gmail.com]
> Sent: Friday, September 23, 2016 11:44 AM
> To: Ackermann, Michael <MAckermann@bcbsm.com>;
> Cc: noloader@gmail.com; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <MAckermann@bcbsm.com>;
> wrote:
> >  I am not sure I understand what your reply means?
> >
> > Is it that we should create or even allow an environment to develop,
> where all providers of service cannot  provide effective diagnostics and
> support?   And then see the constituents of these industries collapse
> together.     And only then realize we have an issue?
> > I hope I am  not understanding correctly.     IETF is supposed to be
> looking ahead to provide better answers and circumvent predictable
> problems.    Not ignoring,  waiting and then reacting to negative
> situations that can and should be avoided.
>
> What exactly is the problem you are concerned with? As I've pointed out
> previously one can still log the contents of TLS protected
> connections: you do this at the client, or with an intercepting proxy.
> What information does this not get you that you need on the network?
>
> >
> > What I am saying,  in relation to your "Delivering a stable product"
> comment is that over time various industries have learned what it takes to
> "Deliver a stable product".    We did not want to invest millions in these
> debugging networks.   But  we learned the hard way,  that it was necessary.
> > I am not a member of the banking coalition that started this subject,
> nor of the banking industry at all,  but I certainly understand their
> perspective and am concerned about  the same unmanageable future they
> described.
>
> Do  Akami, Cloudlflare and Google magically not have these problems?
> >
> > Thanks
> >
> > Mike
> >
> >
> >
> > -----Original Message-----
> > From: Jeffrey Walton [mailto:noloader@gmail.com]
> > Sent: Friday, September 23, 2016 10:55 AM
> > To: Ackermann, Michael <MAckermann@bcbsm.com>;
> > Cc: BITS Security <BITSSecurity@fsroundtable.org>;; tls@ietf.org
> > Subject: Re: [TLS] Industry Concerns about TLS 1.3
> >
> > On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <
> MAckermann@bcbsm.com>; wrote:
> >> From the perspective an Enterprise that runs these applications and has
> invested HEAVILY in the debugging networks.........
> >>
> >> The reason we are debugging these networks is so that "The 5-6 order of
> magnitude of folks using them"  will have good service.   If they do not,
> they will consider competitors and/or generate a litany service calls or
> complaints.        I.E.     When these "Folks"  are slow or not working
> they are just as unhappy as we are.
> >>
> >
> > Isn't that the market operating as expected? Those who deliver a stable
> product at a competitive price are rewarded, while those who fail to
> deliver or deliver at an unreasonable cost are not? (Some hand waiving).
> >
> > If all providers failed to deliver or delivered an inferior product,
> then it might indicate a major course correction is needed. But I don't
> think that's the case here.
> >
> > Jeff
> >
> >
> > The information contained in this communication is highly confidential
> and is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue Cross and
> Blue Shield Association.
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>