Subject: [TLS] draft-ietf-tls-session-hash-04 and session resumption

From: David Benjamin <[email-masked]>
Date: Fri, 10 Apr 2015 23:25:53 +0000

Sorry this is rather late feedback. I was looking at the new session
resumption provisions in draft-ietf-tls-session-hash-04, and one seems
problematic.

So, the draft has some SHOULDs which disable all EMS-less session
resumption:

> The client SHOULD NOT offer an abbreviated handshake to resume a session
that does not use an extended master secret.

> If the new ClientHello does not contain the "extended_master_secret"
extension, the server SHOULD fall back to a full handshake by sending a
ServerHello that rejects the offered session but continues with a full
handshake.

> If the new ServerHello does not contain the "extended_master_secret"
extension, the client SHOULD abort the handshake.

I suspect most implementations will ignore them for the time being.
Assuming they're ignored, being only SHOULDs,

> 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 abort the handshake.

Consider a client which persists sessions to disk and then upgrades with
EMS support. Alternatively, the server may have since upgraded while
retaining the session cache. This can cause a client to offer an EMS-less
session to an EMS-ful server. This MUST now causes the server to abort the
handshake, which is rather unfriendly. Instead, I propose it change to:

> 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 reject the session and fall back to a full handshake.

The new session will still be EMS-ful and we don't risk hard-to-diagnose
failures.

David

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Apr 2015 18:42:51 -0700

>> MUST reject the session and fall back to a full handshake.

WFM.

... MUST reject the session *resumption* and fall back ...

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 13 Apr 2015 10:26:36 +0200

How about the following:
      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 fall back to a full handshake by
      sending a ServerHello that rejects session resumption and offers a
      new session.

On 11 Apr 2015, at 03:42, Martin Thomson <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Emilia Kasper <[email-masked]>
Date: Mon, 13 Apr 2015 11:20:04 +0000

>       sending a ServerHello that rejects session resumption and offers a

Falling back cannot always be indicated in the ServerHello. In particular,
if the client is resuming with a ticket and without a session ID, then
there is nothing special in the ServerHello that says "resuming/not
resuming".

So I think that David's wording is as precise as you can/need to be there.

Emilia

---

From: [email-masked] (Martin Rex)
Date: Wed, 15 Apr 2015 03:53:13 +0200 (CEST)

>       sending a ServerHello that rejects session resumption and offers a

Too complicated for my taste.  I do not see a need for words like
fallback and reject, and these actually do not exist in the TLS protocol.

     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 perform a full handshake to negotiate
     a new session (i.e. the server MUST NOT perform an abbreviated
     handshake aka session resume).

-Martin

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 15 Apr 2015 08:15:08 +0200

I like Martin’s text, and have edited it to the following:

    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 continue the abbreviated handshake.
    Instead, it SHOULD perform a full handshake to negotiate a new session.

If this looks acceptable, I’ll put out a new version of the draft today.

-K.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 15 Apr 2015 09:38:20 +0200

I guess my question is whether “SHOULD perform a full handshake” is strong enough,
leaving the server the option of aborting the handshake, or is MUST preferable
as a clearer indication to implementers?

---

From: David Benjamin <[email-masked]>
Date: Wed, 15 Apr 2015 13:31:31 +0000

Personally, I dislike unnecessary wiggle room in specs and mildly prefer
MUST. I don't see a good reason to abort rather than do a full handshake.
It'd be nice to have the confidence that (non-buggy) servers won't cause
problems here and take a shortcut. (E.g., I can see aborting being simpler
in OpenSSL since it parses most extensions after session resumption is
resolved. The ticket is handled special.)

Then again, one might read MUST to imply the server is obligated to perform
a full handshake and isn't allowed to abort for other reasons, which would
be poor.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Apr 2015 09:39:31 -0700

> as a clearer indication to implementers?

This is fine with me.  Though I think David's concerns are worth
taking into account.  You might instead say:

   Instead, it MUST either perform a full handshake or abort the connection.

That leaves plenty of options open.

Given that this only arises if you have a busted client, we shouldn't
worry too much about which option people take.  If this were an
expected situation somehow, I'd be arguing more strongly for the full
handshake option.

---

From: David Benjamin <[email-masked]>
Date: Wed, 15 Apr 2015 16:52:20 +0000

> expected situation somehow, I'd be arguing more strongly for the full

Not necessarily; it can also occur if the server changes configuration to
add EMS support. Server deployments may not necessarily flush their session
cache across upgrades (perhaps you configured SSLSessionTicketKeyFile in
Apache to share your session cache between machines). It would be nice if
they did, but not everyone running a server will know the nitty gritty
details of what the latest software update included and the interactions
with protocol subtleties.

I agree it's not likely to be very common, so it's not actually that big a
deal. But this is a case where the safer option is clear and not actually
more complex, so the spec should nudge implementers toward that one.

(From experience, interop problems around session resumption are a headache
to diagnose and reason about. I prefer to actively avoid introducing them
where possible.)

David

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Apr 2015 10:00:47 -0700

On 15 April 2015 at 09:52, David Benjamin <[email-masked]> wrote:
> add EMS support.

Oh, of course.  In which case, I am going to more strongly advocate
for the SHOULD text.  I understand that you might have some issue
complying with that for various reasons related to your implementation
or deployment, but this is exactly what SHOULD is for.

I don't want to end up in a situation where the incentives are such
that you resume a session that didn't have session hash, when both
peers support fully support the feature.