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

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 <ynir.ietf@gmail.com> wrote:

>
> > On Nov 24, 2014, at 1:58 PM, Stephen Checkoway <s@pahtak.org> wrote:
> >
> >
> > On Nov 24, 2014, at 3:44 AM, Yoav Nir <ynir.ietf@gmail.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>