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

[Karthikeyan Bhargavan <[e-mail]>]

> 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.
We use SHOULD NOT for these cases; after being advised that MUST NOT is too strong for legacy interop.

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

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


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