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

[Eric Rescorla <[e-mail]>]

This does seem pretty far-fetched... And note that if we just required a
complete handshake
at this point, that wouldn't create a total failure.

My vote would be that unless someone speaks up relatively soon, we should
require one
of the two options listed in my message (at MUST).

-Ekr


On Mon, May 25, 2015 at 10:45 AM, Karthikeyan Bhargavan <
[e-mail]> wrote:

> 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
>
>