Subject: [TLS] Triple Handshake Fix.

From: Adam Langley <[email-masked]>
Date: Tue, 29 Apr 2014 14:05:50 -0700

Without a fix for the Triple Handshake issues[1], TLS Channel Bindings
(at least tls-unique) have a significant problem, not to mention
client-auth.

Microsoft and ourselves are looking to implement the proposed fix[2]
soon. I'd like to request that the WG adopt the draft and that the
process for early codepoint assignment for the TLS extension start.

I think the change to the master secret calculation is relatively
uncontroversial (and is probably what the master secret should always
have been). People might have differing opinions on the SCSV, but that
doesn't affect whether a TLS extension number will ultimately be
allocated for it.

[1] https://secure-resumption.com
[2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt

Cheers

AGL

---

From: Alfredo Pironti <[email-masked]>
Date: Tue, 29 Apr 2014 23:31:32 +0200

I've uploaded the draft to the IETF repository [1].

A tentative implementation of the fix for OpenSSL is available at [2].
(This patch currently also includes a "secure resumption" extension, which
would become unnecessary if the master secret derivation is fixed; I'm
willing to cleanup the patch if there's interest in it).

Cheers,
Alfredo

[1] http://www.ietf.org/id/draft-bhargavan-tls-session-hash-00.txt
[2]
https://secure-resumption.com/patches/OpenSSL1_0_1e-session_hash-extended_ms-secure_resumption.patch

On Tue, Apr 29, 2014 at 11:05 PM, Adam Langley <[email-masked]> wrote:

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

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 29 Apr 2014 23:31:56 +0200

Hi,

> [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt

A comment about the draft:

Section 5.3 states:

    In its ClientHello message, a client MUST either send the
    "extended_master_secret" extension, or the
    "TLS_EXTENDED_MASTER_SECRET" SCSV.  Clients SHOULD NOT include both.

In my opinion, the "SHOULD NOT" ought to be a "MUST NOT", *unless* the  
document also states something like "Servers MUST accept ClientHello  
messages that contain both the "extended_master_secret" extension and the  
"TLS_EXTENDED_MASTER_SECRET" SCSV, and treat them as if only one had been  
received"

When I originally implemented the Renego Information extension in Opera, I  
decided to send both, since deciding when to send either complicates the  
code, at least a little. However, I had to eventually change the code to  
send only one of them (SCSV in extension less handshakes, extension  
otherwise), as 4.7% of Renego patched servers does not tolerate the  
combination, some of them major sites like Linkedin and Paypal.

A SHOULD NOT means that the server may encounter handshakes with both, and  
since server vendors apparently are apt to think that "either" and "SHOULD  
NOT include both" in combination means "MUST NOT include both", then the  
document should either specify how the server should handle reception of  
both indicators, or say that both are forbidden.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Nico Williams <[email-masked]>
Date: Tue, 29 Apr 2014 17:02:49 -0500

> (at least tls-unique) have a significant problem, not to mention

tls-unique is fine provided resumption isn't broken.  Resumption is
broken.  There is a proposed fix[2] that IMO is correct and works.

Of course, apps need to know when tls-unique is safe, but since it's
only not safe when using TLS implementations where resumption isn't
safe...  there's not much that can be done other than to disable
tls-unique at build time or find a way to detect safety at run time.

> process for early codepoint assignment for the TLS extension start.

+inf

> [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt

Yes.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Wed, 30 Apr 2014 00:06:10 +0200 (CEST)

> "TLS_EXTENDED_MASTER_SECRET" SCSV, and treat them as if only one had been  

The only problem is having two seperate indicators with the exact same
meaning in the first place.  Kill the ClientHelloExtension,
have everyone use the SCSV in ClientHello all the time.

> combination, some of them major sites like Linkedin and Paypal.

The by far simplest approach is to send SCSV on all initial handshakes
plus on old-style renegotiation handshakes, and the TLS extension
on all renegotiation handshakes.  KISS -- smaller and simpler code.
So far I have not received any reports about interop problems with
my implementation.

> both indicators, or say that both are forbidden.

Imperatives should only be used when they're absolutely necessary, so
here we have the situation where we need a MAY if we can not get rid
of the ClientHelloExtension.

Unfortunately, the poor choice of defining both for rfc5746 made it likely
that a few superficial implementors get the combination wrong.

Remember Mike's description?

https://www.ietf.org/mail-archive/web/tls/current/msg05456.html

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Apr 2014 16:11:39 -0700

> broken.  There is a proposed fix[2] that IMO is correct and works.

So the proposed fix doesn't do anything about resumption, it changes
the derivation of the master secret.

I think that the proposed fix is the right one - one we should be
fixing for TLS <=1.2.  There are probably better options for fixing
1.3.

---

From: Geoffrey Keating <[email-masked]>
Date: 29 Apr 2014 15:49:21 -0700

> [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt

I read this and couldn't work out how it interacted with
renegotiation.  I'm surprised there's no discussion of renegotiation
at all in section 3.  Does 'handshake_messages' include:

a) Only the first handshake; or

b) Only the last handshake; or

c) All messages from all handshakes, up to the Client Key Exchange
message in each handshake; or

d) All messages from all handshakes, up to the Client Key Exchange
message in the last handshake, up to the Finished message in previous
handshakes, including any HelloRequest messages; or

e) Like d but without HelloRequest messages; or

f) Other?

I'm fairly sure a and b lead to security vulnerabilities.  I'm not
sure whether c does so or not.

d and e present some challenges for implementations with TLS 1.2,
because you could renegotiate to a different hash algorithm, so you
need to keep the contents of the handshake(s), or all possible partial
hashes, for the duration of the connection.

I also note that the draft leaves out the (last?) 'certificate verify'
message, is that intentional?  Are there any security consequences?

---

From: Nico Williams <[email-masked]>
Date: Tue, 29 Apr 2014 18:42:57 -0500

> So the proposed fix doesn't do anything about resumption, it changes

That's quibbling.  Something is broken in TLS leading to tls-unique CB
being vulnerable among other things.  There is a fix that effectively
channel binds the new connection to the one being resumed, and this
naturally solves the problem.

> the derivation of the master secret.

Right.

> fixing for TLS <=1.2.  There are probably better options for fixing

I agree as to fixing TLS <= 1.2.  I don't think there is a better
option for 1.3 (short of removing resumption, as some have proposed),
therefore it's also the correct fix for 1.3 (assuming no major changes
like dropping Finished messages as Watson Ladd proposed, which would
require updating tls-unique concurrently).

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Tue, 29 Apr 2014 17:50:53 -0700

> require updating tls-unique concurrently).

There were two parts to my suggestion: the first was analogous to the
proposed fix. The second was, now that the master secret depends on
the handshake, dispensing with the Finished message. I wasn't
proposing to do the second only: that would lead to security issues,
as nothing would protect the extensions offered.

I'd like to see substantial revampment of Finished. I think we do need
it to prevent some trivial replays (I open a connection but don't send
anything) which might be annoying in some circumstances. But I think
the previous design had unnecessarily been an obstacle to academic
analysis, for an annoying technical reason, and I don't see how this
fix interacts with changing the Finished message in TLS 1.3.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 30 Apr 2014 14:30:10 +0200

> have everyone use the SCSV in ClientHello all the time.

Right. Formally, we need at least an imaginary ClientHello extension for
this (because, in general, "An extension type MUST NOT appear in the
ServerHello unless the same extension type appeared in the corresponding
ClientHello"), but if we're going to require servers to honor the SCSV
anyway, there's no technical reason to allow clients to send something
else.  (Unlike the RFC 5746 secure renegotiation extension, this one never
contains data, so for clients the SCSV is always sufficient.)

For aesthetical reasons, maybe the SCSV should only be used if the
ClientHello omits the extensions field entirely, but even that
unnecessarily complicates server implementations.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 30 Apr 2014 14:15:58 +0200

Alfredo Pironti <[email-masked]>:

> [1] http://www.ietf.org/id/draft-bhargavan-tls-session-hash-00.txt

Thanks, but haven't we seen that this alone doesn't actually fix the
problem?  I think we'll need a requirement for clients and servers
implementing this spec to do one of the following, because an attacker
can't be expected to opt in to extended master secrets in its handshakes:

(1) If the current session does not use an extended master secret, don't
allow renegotiation.

(2) If a session does not use an extended master secret, don't allow it to
be resumed.

Approach 2 arguably is cleaner, but since it would entirely prevent session
resumption between updated implementations and legacy implementations, it's
probably not viable to roll out immediately.  Maybe for servers you'd
initially want to pick either approach 1 or approach 2 depending on the
particular needs (whether renegotiation is needed at all), while clients
initially could allow *both* renegotiation and resumption for new sessions,
where whichever comes first for a given session would disallow the other.
 Eventually, once support for extended master secrets is reasonably
widespread, everyone should switch to approach 2.

Bodo

I think this is still missing a requirement for clients and servers that
implement the fixed

---

From: Karthik Bhargavan <[email-masked]>
Date: Wed, 30 Apr 2014 15:20:03 +0200

> a) Only the first handshake; or

for each session, handshake_messages includes messages in the full
handshake that set up the session.
each full renegotiation handshake sets up a new session and hence a new
session hash.

the session hash countermeasure is meant to link resumed connection with
the original connections where the session was created.
independently, we still need renegotiation indication (rfc4726) to link
different handshakes on the same connection.
in other words, the session hash complements rfc5746, it does not replace
it.

> message, is that intentional?  Are there any security consequences?

CertificateVerify is not part of the handshake_messages on purpose, since
the SSL 3.0 CertificateVerify message uses the master secret.
So, to be backward compatible with SSL 3.0, we need to compute the master
secret before this message.

Is there a ciphersuite where the CertificateVerify message carries new
contextual information that is not present in the previous messages?
In the key exchanges we have looked at, excluding this message seems to be
safe (e.g. the client certificate is in a previous Certificate message).

-K

---

From: Karthik Bhargavan <[email-masked]>
Date: Wed, 30 Apr 2014 15:25:09 +0200

On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller <[email-masked]> wrote
>
>  <http://www.ietf.org/id/draft-bhargavan-tls-session-hash-00.txt>
>>

I agree that the first approach is probably more palatable for legacy
applications. We should require no-renegotiation, and strongly recommend
that application not use channel bindings or exported TLS keys (or PRFs) in
this case.

>
> Approach 2 arguably is cleaner, but since it would entirely prevent
> session resumption between updated implementations and legacy
> implementations, it's probably not viable to roll out immediately.  Maybe
> for servers you'd initially want to pick either approach 1 or approach 2
> depending on the particular needs (whether renegotiation is needed at all),
> while clients initially could allow *both* renegotiation and resumption for
> new sessions, where whichever comes first for a given session would
> disallow the other.  Eventually, once support for extended master secrets
> is reasonably widespread, everyone should switch to approach 2.
>
> Bodo
>
>
>
>
>
>

---

From: Geoffrey Keating <[email-masked]>
Date: 30 Apr 2014 15:04:58 -0700

> in other words, the session hash complements rfc5746, it does not replace

So, I think the draft actually means b out of my original list of
choices.  I would not have guessed that.

The draft definitely needs to explain this.

The draft should also say something about requiring RFC5746.

Would it be better if we tweaked this draft so that if you use it you
don't need RFC5746?  It would be easy to do so and would make the
analysis simpler.  You could just include the previous Finished
messages in the hash, I think.

There should also be something in the security considerations section
about message sequence.  Some implementations might accept, say, a
second ServerCertificate message before the Finished, which would probably
be bad.

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 Apr 2014 17:09:54 -0500

On Wed, Apr 30, 2014 at 8:25 AM, Karthik Bhargavan
<[email-masked]> wrote:
>> implementing this spec to do one of the following, because an attacker can't
>> be expected to opt in to extended master secrets in its handshakes:
>>

Why not both?

> that application not use channel bindings or exported TLS keys (or PRFs) in

That's difficult.  It requires first-class APIs for getting CB, which
many libraries lack.

Nico
--