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

[David Benjamin <[e-mail]>]

On Tue, May 26, 2015 at 12:56 PM Ilari Liusvaara <
[e-mail]> wrote:

> 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 don't think it does. The text is:

   o  If the original session did not use an extended master secret but
      the new ServerHello does contain the "extended_master_secret"
      extension, the client MUST abort the handshake.

   o  If the new ServerHello does not contain the
      "extended_master_secret" extension, the client SHOULD abort the
      handshake.  If it continues with an abbreviated handshake in order
      to interoperate with legacy peers, then the considerations in
      Section 5.4 apply.

The latter applies if an EMS-less server resumes an EMS-full session. This
is what you described. The former applies if an EMS-full server resumes an
EMS-less session. That one shouldn't cause interop problems assuming all
EMS-full servers honor this MUST:

   o  If the original session did not use an extended master secret but
      the new ClientHello does contain the "extended_master_secret"
      extension, the server MUST NOT perform the abbreviated handshake.
      Instead, it SHOULD continue with a full handshake to negotiate a
      new session.

Whereas an EMS-less server may be able to parse a serialized EMS-full
session and attempt to resume it. (In the case of OpenSSL, even if the
structure version gets bumped, d2i_SSL_SESSION kindly ignores the version
field because why not[*]? Though I suppose the structure's syntax could
just get changed incompatibly to break the parse.)

David

[*] I believe the rewrite of that code in the master branch will actually
check it, but 1.0.2 and before don't.