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

[Ilari Liusvaara <[e-mail]>]

On Tue, May 26, 2015 at 10:05:04AM +0200, Karthikeyan Bhargavan wrote:
> > Also, there are two dangerous scenarios:
> > - You have non-session_hash session and resume that.
> > - You try to use TLS-Exporter in non-session_hase session for authentication.
> > 
> > Based on this, it would seem to be the safest to:
> > - Not offer any non-session_hash sessions for resumption.
> > - Deny resumption (full handshake) of any non-session_hash sessions, regardless
> >  of client session_hash support.
> > - Disable TLS-Exporter in non-session_hash sessions.
> 
> 
> It’s worth checking, but I believe these cases are covered in the spec.

The current spec seems to say:
- F->F: SHOULD abort
- F->T: MUST NOT resume (server), SHOULD NOT attempt resume (client)
- T->F: SHOULD abort (this is a weird case)
- T->T: (nothing)

> We use SHOULD NOT for these cases; after being advised that MUST NOT is too strong for legacy interop.

AFAICT, the first two still give interop, just with reduced performance
(full handshakes instead of resumptions).

The third breaks protocols that use TLS-Exporter, including just for keying,
which is seemingly not affected by THS unless one resumes (one can't expect
any security from bad connection).

> > The following are odd edge cases (assuming both ends are due endpoints, these
> > are safe):
> > - Resume session_hash-enabled session wihout session_hash extension
> > - Resume session_hash-enabled session with non-session_hash server.
> 
> Indeed these are the cases that Ekr is objecting to.
> In the current draft we say SHOULD NOT for these, and Ekr suggests it should be MUST NOT.
> Formally, these cases are “safe” in the sense that they are protected by the extended master secret on the first handshake.
> In practice, they are a bit weird because it looks like the connection security degraded between the two handshakes.

AFAICT, if these can actually happen in practice, aborting does create
interop problems.

> The question is whether these could happen in practice, and I would welcome more thought son that.

Could the scenario I gave (quoted below) happen in practice (it causes
resumption of session_hash-enabled session with non-session_hash server)?

> > I was thinking latter of those odd behaviours could occur if one performs
> > rolling security fix of server farm:
> > - Client is security fixed
> > - Server A is security fixed
> > - Client connects to A
> > - Client gets session_hash-enabled session.
> > - Client connects to B, attempting to resume.
> > - Servers share session DB/key, so resumption succeeds.
> > - Client gets resumption without session_hash extension.


-Ilari