Subject: [TLS] question on draft-ietf-tls-session-hash-03

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 09:21:52 -0500

I have a question on draft-ietf-tls-session-hash-03. In the description 
I see:

    As described in [TRIPLE-HS  <https://tools.ietf.org/html/draft-ietf-tls-session-hash-03#ref-TRIPLE-HS>], in both the RSA and DHE key exchanges,
    an active attacker can synchronize two TLS sessions so that they
    share the same "master_secret".  For an RSA key exchange where the
    client is unauthenticated, this is achieved as follows.  Suppose a
    client, C, connects to a malicious server, A.  A then connects to a
    server, S, and completes both handshakes.  For simplicity, assume
    that C and S only use RSA ciphersuites.  (Note that C thinks it is
    connecting to A and is oblivious of S's involvement.)

My question is on the parenthetical comment at the end. I'll repeat it 
here, expanding C, S and A into CLIENT, SERVER and ATTACKER, respectively:

					(Note that CLIENT thinks it is
    connecting to ATTACKER and is oblivious of SERVER's involvement.)

Am I wrong in thinking that A and S are reversed here, and this should read:

					(Note that CLIENT thinks it is
    connecting to SERVER and is oblivious of ATTACKER's involvement.)

Or, removing the expansion:

					(Note that C thinks it is
    connecting to S and is oblivious of A's involvement.)

That is, ATTACKER A is the malicious man in the middle that the client 
is not aware of. (For that matter, the server is also probably oblivious 
of A's involvement.)

     Tony Hansen

---

From: Benjamin Beurdouche <[email-masked]>
Date: Tue, 24 Feb 2015 09:47:28 -0500

Hi Tony,

To me it seems the sentence is correct as C really wants to connect to A thinking it is an honest server and doesn't know S is involved. Then S doesn't know the involvement of A as A connected unauthentified and forwards info from C.
But authors should confirm that in case I am mistaken...

Cheers,
B.

> On 24 Feb 2015, at 9:21 am, Tony Hansen <[email-masked]> wrote:
> 
> I have a question on draft-ietf-tls-session-hash-03. In the description I see:
> 
>    As described in [TRIPLE-HS], in both the RSA and DHE key exchanges,
> My question is on the parenthetical comment at the end. I'll repeat it here, expanding C, S and A into CLIENT, SERVER and ATTACKER, respectively:
> 
> That is, ATTACKER A is the malicious man in the middle that the     client is not aware of. (For that matter, the server is also probably oblivious of A's involvement.)
> 
>     Tony Hansen
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 10:12:07 -0500

Thank you for the quick response. In my interpretation, I took things as 
"C really wants to connect to S, but got A instead". I didn't get your 
interpretation when I read it and re-read it. But I can see now how what 
you wrote would also be a valid interpretation.

I guess we'll await a response from the authors.

     Tony Hansen

Benjamin Beurdouche <benjamin.beurdouche at inria.fr 
<mailto:[email-masked]>> wrote:
> Hi Tony,
>
> To me it seems the sentence is correct as C really wants to connect to 
> A thinking it is an honest server and doesn't know S is involved. Then 
> S doesn't know the involvement of A as A connected unauthentified and 
> forwards info from C.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 24 Feb 2015 19:16:03 +0100

Yes, C wants to connect to A. A independently connects to S.
So in the outer TLS connection, there is no attack. (A is like an application-level proxy.)

Then during renegotiation after resumption, C authenticates with a client certificate to A
and A succeeds in forwarding C’s certificate to S, hence impersonating C at S.

There are other variations of the attack on various TLS channel bindings, 
but the above version (initial + resumption + renegotiation) is called the triple handshake attack.

Perhaps we could be a bit clearer about this in the spec? I am currently revising it to incorporate other comments on the list.

Best,
-Karthik

On 24 Feb 2015, at 16:12, Tony Hansen <[email-masked]> wrote:

> Thank you for the quick response. In my interpretation, I took things as "C really wants to connect to S, but got A instead". I didn't get your interpretation when I read it and re-read it. But I can see now how what you wrote would also be a valid interpretation.
> 
> Benjamin Beurdouche <benjamin.beurdouche at inria.fr> wrote:
>> Hi Tony,
>>

---

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 13:58:13 -0500

Thank you for the clarifications Karthik.

Here is one suggestion for changing the text:

Change:
     Suppose a client, C, connects to a malicious server, A. A then 
connects to a
     server, S, and completes both handshakes.
to:
     Suppose a client, C, connects to an application server, A. C does 
now know
     that A is also malicious and that A connects in the background to 
another
     server, S. A connects to S and completes both handshakes.

Or possibly take some of your text you just posted and add that in.

On 2/24/15 1:16 PM, Karthikeyan Bhargavan wrote:
> Perhaps we could be a bit clearer about this in the spec? I am 
> currently revising it to incorporate other comments on the list.
>
> Best,
> -Karthik
>
> On 24 Feb 2015, at 16:12, Tony Hansen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Thank you for the quick response. In my interpretation, I took things 
>> as "C really wants to connect to S, but got A instead". I didn't get 
>> your interpretation when I read it and re-read it. But I can see now 
>> how what you wrote would also be a valid interpretation.
>>
>>> To me it seems the sentence is correct as C really wants to connect 
>>> to A thinking it is an honest server and doesn't know S is involved. 
>>> Then S doesn't know the involvement of A as A connected 
>>> unauthentified and forwards info from C.
>> [email-masked] <mailto:[email-masked]>