Re: [TLS] Industry Concerns about TLS 1.3

Yoav Nir <ynir.ietf@gmail.com> Tue, 27 September 2016 18:27 UTC

Return-Path: <ynir.ietf@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 BE7F612B31F for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 11:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Eh7CYJ_tSLPx for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 11:27:54 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c: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 1328012B21A for <tls@ietf.org>; Tue, 27 Sep 2016 11:20:36 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id w84so191115131wmg.1 for <tls@ietf.org>; Tue, 27 Sep 2016 11:20:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VcQsH9eM6kpk7KPgajEY+DXt4pm4MxBXZxYE7u9+tTs=; b=me6GnSVa/cyMbxbDXStwJLgczh0POjpO2/7LqpwJu8kYclmgOlj5JeN6QKRbZW6pZB 5Rd58WzAuz1IzfGN9gZr7lrf6Fc8C1PDm12tDITHdqiFJP/dwRf+kjU15IBz4FwJ021h xIe1w3Otu1f4WzQVCYhz0meeSRy3KHbbE0ZkCHxCh5lpv8FyoVgajn349cfceXqnTprJ HQCLmSRtSl/cZnGT00gTBSTh1G6s+3m6mht3Ok7KYloKEBhvCAbBgK0UdoYJNYX0OsA1 ood9euZoiZJed1PXq4WQxMTWUEhirw+G5FAXy4DNR1eyOmwnwlShrFIToK/HtB2ji4LO gVTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VcQsH9eM6kpk7KPgajEY+DXt4pm4MxBXZxYE7u9+tTs=; b=ebIyhF2KCdkGhNuvLe+hkBWaSokZ8BGQV6e8r4Uw65Y/K9/SVkH8LZmj8JDjdR4NBR 7wQmdtPu4EAkqgjJrBUSbgnGhuiEvdsqOUnHQ7ihGwpWpOFUAUpgkgqmy2g1gLTd4pSP rFaPzi4pRymwMPx9J6/ZFX2gutSqPAnWWYgVLlV9+ihIox6UvCvrfC82XIuDbRZ0ceia yhebZ6k3TjAp/G/5+G3CMWWqVYqM3CEq9v+HAlVRjX3OIUQZWWvz+2/nmzZk23xe7CqU Bsu2Kw9duvnp9nvoWCbsDFRYX3YvyRkrc/dTDpfV36+RPKdryEo5vZ1UjiXs1GPAFlEI 3Aag==
X-Gm-Message-State: AA6/9RndZVS9HF8aT0cf9ElQY1+0UwPNR40Vji5GDnkrxeVnPgiq4uE/MEonitKewG3eeA==
X-Received: by 10.28.31.7 with SMTP id f7mr4116608wmf.69.1475000434262; Tue, 27 Sep 2016 11:20:34 -0700 (PDT)
Received: from [10.4.240.86] ([82.102.169.113]) by smtp.gmail.com with ESMTPSA id n7sm4379395wmf.18.2016.09.27.11.20.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 11:20:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6FE8D014-5E4B-4DCB-A821-B1D50C29AD0E"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAB=4g8KqrO5EN20rawExHoM3qw9S8se8vQJupK0_A_8o8Dytiw@mail.gmail.com>
Date: Tue, 27 Sep 2016 21:20:27 +0300
Message-Id: <39D236B0-30DC-4233-BB25-A99A47B5A2F8@gmail.com>
References: <DM5PR11MB14191AABED7E43F904133787F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <r470Ps-10116i-4C64C69C85D443BF91A20D2FDB8F48E9@Williams-MacBook-Pro.local> <DM5PR11MB1419320109EC18605B1D2072F4CD0@DM5PR11MB1419.namprd11.prod.outlook.com> <BD40CD6E-568F-40A3-838F-C4AC9C9AF9C8@dukhovni.org> <CABcZeBNKzr7tmYPz2BBt=cSvLnhniUosSbHZCU8qS42bXoO=_g@mail.gmail.com> <11BA66BB-3B08-4170-8F84-A06E1B4214AC@dukhovni.org> <CAB=4g8KqrO5EN20rawExHoM3qw9S8se8vQJupK0_A_8o8Dytiw@mail.gmail.com>
To: Judson Wilson <wilson.judson@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IKKHjXU_Um7QV5nzqOUW810tID8>
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: Tue, 27 Sep 2016 18:27:57 -0000

> On 27 Sep 2016, at 11:33 AM, Judson Wilson <wilson.judson@gmail.com>; wrote:
> 
> 
> 
> Yes, I know that changed.  It was an example of something that works with
> TLS 1.2 even when PFS is used.  With TLS 1.3 server or client implementations
> can find other ways to retain long-term records of session keys.  The capability
> to do that is not a requisite or desirable protocol feature.  Different user
> communities will have different needs, and the best solution is to provide
> security by default, and cede control of the result to the endpoints.
> 
> 
> I don't believe that storing this information on the endpoints is a great idea, simply because the monitoring equipment will have a difficult time ensuring that the information exists when it is needed. It also increases the number of sites that are risks to compromising past data. 

Assuming clients are browsers for the most part, storing information there is not robust. The servers or load balancers OTOH are small in number and controllable. If they store a static or time-limited server keyshare or even actual session keys it can be made to work. As for ensuring that the information is stored, that is true regardless of what regulations require to be stored.

> I think this challenge is best solved by putting the information on the wire in some way, possibly as a special industry-specific extension (used only by those who are bent on shooting themselves in the foot).

Like this?
https://tools.ietf.org/html/draft-nir-tls-keyshare-02

But this doesn’t work if you’re using a standard browser. This draft was a strawman proposal for some argument. Even if we liked this and wanted to make this an RFC, I can’t see the likes of Google or Mozilla implementing this in their browsers. Or you’d need a fork of some server-side library. OpenSSL-with-keyshare?  Because I don’t see it popping up in the regular OpenSSL.  That’s a good thing.

> The benefit being that if the TLS channel is alive, the session information is available to the monitor.  Just as a strawman, the client could transmit session info in special records, encrypted by a public key, and the monitoring equipment could scoop these up. For compatibility with servers outside the network, a middlebox could somehow filter out these records.
> 
> It sounds like the need is large enough that such an effort is feasible, and it would be good to keep normal TLS 1.3 unambiguously forward secure. (There IS still the question of how to make sure that the extension is not enabled in endpoints it shouldn't be.)
> 
> On Mon, Sep 26, 2016 at 5:20 PM, Viktor Dukhovni <ietf-dane@dukhovni.org <mailto:ietf-dane@dukhovni.org>> wrote:
> 
> > On Sep 26, 2016, at 7:21 PM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
> >
> > There are other ways to accomplish this.  For example, the server might
> > use session ticket keys that are stored centrally encrypted under a
> > suitable escrow key.  If clients always enable session tickets, then
> > every handshake will result in the server returning a session ticket,
> > in which case the session can be later decrypted if the session ticket
> > keys are available.
> >
> > This actually doesn't work in TLS 1.3 because the resumption master secret
> > is not sufficient to decrypt the connection in which it was established.
> 
> Yes, I know that changed.  It was an example of something that works with
> TLS 1.2 even when PFS is used.  With TLS 1.3 server or client implementations
> can find other ways to retain long-term records of session keys.  The capability
> to do that is not a requisite or desirable protocol feature.  Different user
> communities will have different needs, and the best solution is to provide
> security by default, and cede control of the result to the endpoints.
> 
> --
>         Viktor.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls