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

[David Benjamin <[e-mail]>]

On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara <[e-mail]>
wrote:

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

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.

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.

For the converse case (client offers an EMS-ful session on an EMS-less
connection, draft says server SHOULD abort), I can't think of a deployment
where this could happen in practice. The analogous "server farm" case seems
less likely for a client, so aborting seems fine. Still, I don't see a need
for the abort, so I would marginally prefer either "fall back to a full
handshake" (unlike the client, the server has this option) or "just behave
as you otherwise would and inherit whatever EMS-ful => EMS-less tls-unique
considerations we adopt above".

It's slightly confusing that the text tries to specify everything with a
single menu of SHOULDs to pick and choose. It's seems there's only two
profiles to worry about: "EMS required" and "EMS optional due to interop
needs". In fact, the two SHOULDs we're talking about don't even explicitly
talk about the EMS-ful session => EMS-less resumption case. They just say
to abort period, which is mostly for the "EMS required" profile.

David