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

[Ilari Liusvaara <[e-mail]>]

On Tue, May 26, 2015 at 04:41:37PM +0000, David Benjamin wrote:
> On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > 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.
> >
> 
> This could certainly happen with a server farm, yeah. Hopefully such a
> situation would be rather transient, and it can be mitigated by sharding
> the session cache between EMS-less and EMS-ful halves of the rollout. But
> relying on it always happening seems unrealistic, so honoring the SHOULD is
> a little risky.

IIRC, this hits MUST. That is, the client is REQUIRED to abort in this
case.
 
> I would think tls-unique and friends are still fine in this case? Though if
> we're worried about it (maybe we introduce some new extension later and
> would rather it be incorporated into the key derivation?), we could just
> say that the client should still disable tls-unique and whatnot. I.e.
> IsTLSUniqueSecure() requires that BOTH the connection and the original
> session, if any, are EMS-ful. That seems appropriately conservative and
> without risk of (transient) interop failures. Client with require interop
> need to account for that returning false anyway.

AFAIK:

If you don't resume, TLS-Unique is fine. TLS-Extractor is not.

If the original connection had EMS, then both TLS-Unique and TLS-Extractor
are fine, regardless of if resumptions do.


-Ilari