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

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Tue, 24 February 2015 14:47 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD51A8713 for <tls@ietfa.amsl.com>; Tue, 24 Feb 2015 06:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vDiNHgU_0fW for <tls@ietfa.amsl.com>; Tue, 24 Feb 2015 06:47:33 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B923A1A1B8E for <tls@ietf.org>; Tue, 24 Feb 2015 06:47:32 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.09,639,1418079600"; d="scan'208,217";a="123188729"
Received: from pool-108-14-101-29.nycmny.fios.verizon.net (HELO [192.168.1.7]) ([108.14.101.29]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2015 15:47:30 +0100
References: <54EC8900.5000904@att.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <54EC8900.5000904@att.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-D0EC0626-7863-4F09-AE29-5650392F598C"
Content-Transfer-Encoding: 7bit
Message-Id: <B95CF8B5-3E37-4A9C-99DB-2B2743759381@inria.fr>
X-Mailer: iPhone Mail (12B466)
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Date: Tue, 24 Feb 2015 09:47:28 -0500
To: Tony Hansen <tony@att.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4nzKHMOTTLK9X0ui7CWFETBy_JM>
Cc: "tls@ietf.org" <tls@ietf.org>, "antoine.delignat-lavaud@inria.fr" <antoine.delignat-lavaud@inria.fr>
Subject: Re: [TLS] question on draft-ietf-tls-session-hash-03
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2015 14:47:35 -0000

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 <tony@att.com> 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,
>    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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls