> > 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. 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). 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-d...@dukhovni.org> wrote: > > > On Sep 26, 2016, at 7:21 PM, Eric Rescorla <e...@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 > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
