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 [...] > I've written up a short proposal with idea about how I'd suggest going > about this
On Saturday, July 18, 2015 12:50:40 am Eric Rescorla wrote: > I don't think this is that useful or practical with the current structure > of TLS 1.3. [...] > - 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). Ok, it looks like this late night idea isn't really needed anymore for at least this set of use-cases. On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > 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.) Ah, so just a simple empty extension would suffice for your main concern. I went with a simple alert to satisfy your 3rd point in the RFE along with 1 and 2. > 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. Ok, then I'll move the other little wording fixes/simplifications in there into my main WIP branch and set this idea aside for the time being. If the ability to easily request an ephemeral TLS session at-will sounds particularly useful to anyone, then we can discuss it further and I could submit a PR. Thanks, Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
