Re: [TLS] More clarity on resumption and session hash

[Karthikeyan Bhargavan <[e-mail]>]

Right, there was discussion on this and here’s the current rationale.

If the original handshake used the extended master secret,
then even if the resumption handshake does not, it is still protected
by the key derivation in the original handshake.

The only situation when I can see this happening is when the resumption handshake goes to different
endpoints than the original handshake (e.g. in WPA), but maybe someone on the list knows better whether the following is a reasonable use case.

The client connects to an access point which forwards the (EAP-TLS) connection to the (Radius) server.
The server speaks TLS + extended master secret and the client and server agree upon a master secret.
The server installs the master secret at the access point, which itself does not support extended master secret.
The client can now communicate directly with the access point,  and also resume (EAP fast reauth) connections directly with access points without the need to recontact the Radius server

A similar scenario can perhaps be envisioned in cases where a server farm of front-ends directs initial connections to a powerful server that supports extended master secret, but resumption handshakes (via session tickets) can be handled by any (legacy) server.

Far fetched?
-K.


On 25 May 2015, at 19:35, Eric Rescorla <[e-mail]> wrote:

> 
> 
> 
> 
> I'm updating the NSS session hash implementation to conform to the new spec
> and I see that it's very clear on what happens when you have a resumption
> where the original handshake did not include the extension and the new one
> does (thanks David and Martin)
> 
>   o  If the original session did not use an extended master secret but
>       the new ClientHello does contain the "extended_master_secret"
>       extension, the server MUST NOT perform the abbreviated handshake.
>       Instead, it SHOULD continue with a full handshake to negotiate a
>       new session.
> 
> However, it's less clear on what happens when the original handshake included
> the extension and the new one does not:
> 
>    o  If the new ClientHello does not contain the
>       "extended_master_secret" extension, the server SHOULD abort the
>       handshake.  If it continues with an abbreviated handshake in order
>       to interoperate with legacy peers, then the considerations in
>       Section 5.4 apply.
> 
> This doesn't seem to distinguish between the two cases (original session
> did and did not use the extension), but they seem different, since the
> original session not using session hash is a common case (legacy) whereas
> an extension->no extension transition is an anomaly. Note that the client
> *is* required to send it, so I think there's a reasonably strong
> argument that the server should require it.
> 
> The two main options appear to be:
> 
>     1. Fall back to a full handshake.
>     2. Abort the connection
> 
> The argument for the first appears to be interop. The argument for the
> second appears to be that it's likely there is an error or a mid-flight
> reconfiguration on the client (which seems not good). My mild preference
> is for abort but I think it's important in any case that the draft be
> clear.
> 
> 
> Similarly, the text about the client side doesn't seem to draw this
> distinction:
> 
>       If the new ServerHello does not contain the
>       "extended_master_secret" extension, the client SHOULD abort the
>       handshake.  If it continues with an abbreviated handshake in order
>       to interoperate with legacy peers, then the considerations in
>       Section 5.4 apply.
> 
> Because above the server is required to provide the extension when
> resuming a session where the extension was negotiated, it seems like
> we should require the client to fail in that case (that's the sense
> of the MUST).
> 
> I see there was some discussion on the list 3/10 but it was inconclusive.
> 
> -Ekr
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls