Dave Garrett <davemgarr...@gmail.com> wrote: > Brian Smith posted an RFE to GitHub a few months ago requesting "A > mechanism is needed to indicate that a session will not be resumed": > https://github.com/tlswg/tls13-spec/issues/137 > > The goal is to provide a simple way for either endpoint to request that > the master secret be forgotten ASAP to provide a greater assurance of > confidentiality. > > I've written up a short proposal with idea about how I'd suggest going > about this: > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify > > The idea is to simply add a new "reset_notify" alert (generally a warning) > which may be sent by either endpoint as soon as record protection is > available, after which both endpoints would stop caching shared secrets > after completion of traffic key completion. This could be sent right from > the start, at the end of a connection just prior to a standard > "close_notify", or at any point in between. >
This is not really what I was intending when I suggested the feature. I was intending for their to be an indication, in the ClientHello, that the server should not do any of the work that it would normally do to make the session resumable. That is, the server MUST NOT create a session ticket, and the server MUST NOT add the connection to any session cache, the server SHOULD forget the epheneral (EC)DHE key and master secret ASAP during handshaking. (And, so should the client.) An alert like you suggest may be useful for some cases, but it wouldn't be useful for what I was suggesting because it would occur after the server has already done all the things to cache a session that add needless risk and waste resources when the client has no intention of resuming the connection. In the context of web browsers, I believe that the Tor Browser would prefer to have this, since it disables session resumption to prevent the leaking of the tracking identifier inherent in it. It would also be useful for any (non-browser) application for which a 1-RTT handshake per connection is good enough, which is probably most applications, especially many server-to-server applications. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
