Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption

[David Benjamin <[e-mail]>]

On Wed, Apr 15, 2015 at 12:40 PM Martin Thomson <[e-mail]>
wrote:

> On 15 April 2015 at 00:38, Karthikeyan Bhargavan
> <[e-mail]> wrote:
> > I guess my question is whether “SHOULD perform a full handshake” is
> strong enough,
> > leaving the server the option of aborting the handshake, or is MUST
> preferable
> > as a clearer indication to implementers?
>
>
> This is fine with me.  Though I think David's concerns are worth
> taking into account.  You might instead say:
>
>    Instead, it MUST either perform a full handshake or abort the
> connection.
>
> That leaves plenty of options open.
>
> Given that this only arises if you have a busted client, we shouldn't
> worry too much about which option people take.  If this were an
> expected situation somehow, I'd be arguing more strongly for the full
> handshake option.
>

Not necessarily; it can also occur if the server changes configuration to
add EMS support. Server deployments may not necessarily flush their session
cache across upgrades (perhaps you configured SSLSessionTicketKeyFile in
Apache to share your session cache between machines). It would be nice if
they did, but not everyone running a server will know the nitty gritty
details of what the latest software update included and the interactions
with protocol subtleties.

I agree it's not likely to be very common, so it's not actually that big a
deal. But this is a case where the safer option is clear and not actually
more complex, so the spec should nudge implementers toward that one.

(From experience, interop problems around session resumption are a headache
to diagnose and reason about. I prefer to actively avoid introducing them
where possible.)

David