Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Dave Garrett <[e-mail]>]

On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett <[e-mail]>
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