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

Karthikeyan Bhargavan <> Tue, 24 February 2015 18:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 96E461A1C03 for <>; Tue, 24 Feb 2015 10:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W3BQQHHCgmeg for <>; Tue, 24 Feb 2015 10:16:07 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B74131A1B59 for <>; Tue, 24 Feb 2015 10:16:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.09,640,1418079600"; d="asc'?scan'208,217";a="123224563"
Received: from (HELO []) ([]) by with ESMTP/TLS/AES128-SHA; 24 Feb 2015 19:16:04 +0100
Content-Type: multipart/signed; boundary="Apple-Mail=_45F32348-FDEF-4B66-A557-4F1000249C68"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Tue, 24 Feb 2015 19:16:03 +0100
Message-Id: <>
References: <> <>
To: Tony Hansen <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Subject: Re: [TLS] question on draft-ietf-tls-session-hash-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Feb 2015 18:16:09 -0000

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.


On 24 Feb 2015, at 16:12, Tony Hansen <> 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.
> I guess we'll await a response from the authors.
>     Tony Hansen
> Benjamin Beurdouche <benjamin.beurdouche at> 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.
>> But authors should confirm that in case I am mistaken...
> _______________________________________________
> TLS mailing list