Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Jan 2015 14:51:10 -0800

So to be clear, the proposed language is:

For sessions negotiated without EMS:
- SHOULD not resume
- MUST not resume sessions if the client offers EMS in the resumption
  (and therefore SHOULD do a complete negotiation).

For sessions negotiated with EMS:
- The client ??? offer EMS
- The server MUST NOT echo it?

I propose that the ??? be MUST and that the server MUST fail if the client
does not offer EMS. The intuition here is that the client is saying that it
wants EMS.

-Ekr

P.S. Thanks to Wan-Teh and Martin for talking this over privately.

On Mon, Nov 24, 2014 at 6:22 AM, Yoav Nir <[email-masked]> wrote:

>
> > On Nov 24, 2014, at 1:58 PM, Stephen Checkoway <[email-masked]> wrote:
> >
> >
> > On Nov 24, 2014, at 3:44 AM, Yoav Nir <[email-masked]> wrote:
> >
> >> Third issue: Why can’t an attacker disable this protection by simply
> omitting the extension from both its ClientHello and ServerHello?  At least
> in the short term it won’t be practical to fail a handshake because the
> other side doesn’t support this extension. I guess the answer is that the
> ruse will work, but the other attacks mentioned in TRIPLE-HS will fail, but
> it’s not clear to me why. A can still proxy unchanged records from C to S
> if the connections are resumptions. Perhaps servers should be prohibited
> from resuming a session set up without this extension if the ClientHello
> does include the extension.
> >
> > The draft currently says "Clients and servers SHOULD NOT resume sessions
> that do not use the extended master secret..." Are you saying you want that
> to be MUST NOT?
>
> I missed that line.
>
> What I was suggesting was that servers MUST NOT resume sessions that were
> negotiated without the extended master secret in handshakes that do have
> the extension.
>
> Thinking it over now, I guess it would be better to have both lines,
> because there’s a significant performance penalty to prohibiting sessions
> resumption with all existing clients, and prohibiting the resumption where
> the attacker is not manipulating the handshake defeats the known attacks.
>
> Yoav
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Jan 2015 15:21:26 -0800

> - The server MUST NOT echo it?

Just to be clear, this latter part is...when renegotiating.

My preference is: if the session had EMS, when renegotiating:
 - the client MUST offer the extension, and
 - the server MUST fail the handshake (new alert needed?) if the
extension isn't present.

That means no resumption, OR fallback to the complete handshake.

I think that I'd prefer to have the server echo the extension in this
case too.  It's a few bytes effectively wasted, but it makes
everything nice and symmetrical.  Clients says "I want EMS" and server
says "you got EMS".

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Jan 2015 15:29:01 -0800

> Just to be clear, this latter part is...when renegotiating.

When resuming, right?

> everything nice and symmetrical.  Clients says "I want EMS" and server

I could live with this as well.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Jan 2015 15:33:20 -0800

> When resuming, right?

My bad, I seem to do that all the time.

---

From: Henrik Grubbström <[email-masked]>
Date: Fri, 16 Jan 2015 11:52:40 +0100

>> Just to be clear, this latter part is...when renegotiating.

Maybe something like the following should be added in TLS 1.3?

A session MUST only be resumed if the server would create an
equivalent session (including the same server certificate and version
of TLS) on resumption failure. On resumption failure the session_id
provided in the ClientHello MUST be invalidated.

Such a rule would ensure that extensions like server_name,
max_fragment_length, truncated_hmac, encrypt_then_mac and
extended_master_secret (where relevant) are kept in the resumption
ClientHello, and that the connection won't be downgraded on resumption
failure.

>> everything nice and symmetrical.  Clients says "I want EMS" and server

Sounds good to me.

/grubba

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]