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

From: Sean Turner <[email-masked]>
Date: Sun, 23 Nov 2014 09:49:42 -1000

This is the working group last call for http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/.  Please review the document and send your comments to the list by Friday, December 12, 2014.  

Thanks,
J&S

---

From: Stephen Checkoway <[email-masked]>
Date: Sun, 23 Nov 2014 19:12:47 -0500

> This is the working group last call for http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/.  Please review the document and send your comments to the list by Friday, December 12, 2014.  

Minor editorial comments:

   Synchronization of the "verify_data" in abbreviated handshakes also
   undermines the security guarantees of the renegotiation indication
   extension [RFC5746], re-enabling a prefix-injection flaw similar to
   the renegotiation attack [Ray09].  However, in a triple handshake
   attack, the client sees the server certificate changing across
   different full handshakes.  Hence, a precondition to mount this stage
   of the attack is that the client accepts different certificates at
   each handshake, even if their common names do not match.  Before the
   triple handshake attack was discovered, this used to be widespread
   behavior, at least among some web browsers, that where hence
   vulnerable to the attack.

1. I think it should be "...accepts different certificates _for_ each handshake..."
2. I'm not entirely sure what the final sentence is saying. It doesn't make sense for "the attack" to refer to the triple handshake attack (which is the most recently mentioned attack). Is it saying that browsers were vulnerable to a prefix-injection attack à la the renegotiation attack (which is referred to as a flaw rather than attack in the paragraph)?
3. "that where hence" should be something else, but I'm not sure what exactly that sentence means.

-- 
Stephen Checkoway

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Nov 2014 10:44:37 +0200

Hi.

I hadn’t read this before, so these issues may have been discussed before. Sorry if I’m wasting time like this.

The following paragraph from the Introduction is weird:

   Similar scenarios can be achieved when the handshake uses a DHE
   ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit
   curve.  Even if the client or server does not prefer using RSA or
   DHE, the attacker can force them to use it by offering only RSA or
   DHE in its hello messages.  Other key exchanges may also be
   vulnerable.

The first sentence says that (EC)DHE ciphersuites are also vulnerable with explicit params. The last sentence talks of "other key exchanges", which in practice means DHE or ECDHE with named groups or curves. But that lower case “may” is content-free. Suppose a new server supports only ECDHE ciphersuites with named curves (there are some popular web sites that do this today), does it also need the session hash extension? This is not covered in either the introduction or the security considerations.

Second issue: The draft does not say whether a server should include the extension in a resumed session. The extension has no effect (as section 5.1 says), but it should be specified one way or the other. I would go for the less meaningless bytes option.

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.

Yoav

> On Nov 23, 2014, at 9:49 PM, Sean Turner <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Adam Langley <[email-masked]>
Date: Mon, 24 Nov 2014 02:36:22 -0800

> The first sentence says that (EC)DHE ciphersuites are also vulnerable with explicit params. The last sentence talks of "other key exchanges", which in practice means DHE or ECDHE with named groups…

I think that last sentence was roughly aimed to mean: "other key
exchanges (i.e. SRP, Kerberos, PSK), and future ones, may also have
properties that allow for this attack. We're not going to worry about
analysing them and instead will solve the problem in general (we
hope)."

But clearly some work tweaking is called for as that's evidently not
completely clear.

> Second issue: The draft does not say whether a server should include the extension in a resumed session. The extension has no effect (as section 5.1 says), but it should be specified one way or the…

Sure, let's say that the server SHOULD NOT echo it. (And I'll make a
note to check my implementations for that.)

> Third issue: Why can’t an attacker disable this protection by simply omitting the extension from both its ClientHello and ServerHello?

Writing this down might be called for too. In practice, I'm
implementing it so that calls to get tls-unique values and the like
will fail on resumed connections where the original session did not
use this extension.

Cheers

AGL

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 04:44:43 -0600

On Mon, Nov 24, 2014 at 02:36:22AM -0800, Adam Langley wrote:
> > Third issue: Why can’t an attacker disable this protection by simply
> > omitting the extension from both its ClientHello and ServerHello?
> 

+1.

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 24 Nov 2014 06:58:48 -0500

> 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 ha…

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?

-- 
Stephen Checkoway

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Nov 2014 16:22:25 +0200

> On Nov 24, 2014, at 1:58 PM, Stephen Checkoway <[email-masked]> wrote:
> 
> 

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 11:31:44 -0600

On Mon, Nov 24, 2014 at 04:22:25PM +0200, Yoav Nir wrote:
> > 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.

Or they must not support tls-unique CB extraction (or the key exporter)
in that case.  But I prefer the "MUST NOT resume" language.

Nico
--