Re: [TLS] Industry Concerns about TLS 1.3

[Yoav Nir <[e-mail]>]

> On 27 Sep 2016, at 11:33 AM, Judson Wilson <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 
> > On Sep 26, 2016, at 7:21 PM, Eric Rescorla <[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls