On Fri, Jul 17, 2015 at 9:37 PM, 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 seems like a simple route that does what is specified in issue #137 > without the creation of any new extensions or messages; just one new alert > value. > > Comments? Suggestions? Any reason this would break everything? > I don't think this is that useful or practical with the current structure of TLS 1.3. - Unless I've missed something, this is primarily an issue of PFS for the original connection, since compromise of either endpoint probably allows impersonation attacks going forward. - Because the resumption master secret is cryptographically independent of the master secret that initiated the connection, its existence in the server's database or in a ticket isn't a threat to the originating connection. - The server can opt not to allow resumption by declining to provide a NewSessionTicket message. - The client has the option of never initiating a new connection with the provided ticket (assuming that the server opts to supply one). Note also that because the ticket is encrypted with the original traffic keys, if the client never tries to resume the connection, the ticket never appears on the wire (which is relevant for self-encrypted tickets, but not so much for tickets which are database lookup keys). - Because many implementations use self-encrypted tickets, it's not practical to require them to delete keying material once it's been established. Once such a ticket has been transmitted on the wire, the server can't really forget it without deleting the ticket encryption key (it can of course mark the ticket invalid in some local database, but that doesn't reduce the risk from compromise of the ticket encryption key.) -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
