Re: [TLS] Verify data in the RI extension?

Eric Rescorla <ekr@networkresonance.com> Fri, 27 November 2009 15:24 UTC

Return-Path: <ekr@networkresonance.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F603A69EC for <tls@core3.amsl.com>; Fri, 27 Nov 2009 07:24:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.087
X-Spam-Level:
X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw+ZWT4dRl2O for <tls@core3.amsl.com>; Fri, 27 Nov 2009 07:24:09 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id A918E3A691B for <tls@ietf.org>; Fri, 27 Nov 2009 07:24:09 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 4B60A6C3797; Fri, 27 Nov 2009 07:24:48 -0800 (PST)
Date: Fri, 27 Nov 2009 07:24:48 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Stefan Santesson <stefan@aaa-sec.com>
In-Reply-To: <C735AA16.6BDF%stefan@aaa-sec.com>
References: <c331d99a0911270630j6a8819e8pbe812fae87437410@mail.gmail.com> <C735AA16.6BDF%stefan@aaa-sec.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20091127152448.4B60A6C3797@kilo.networkresonance.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Verify data in the RI extension?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Fri, 27 Nov 2009 15:24:10 -0000

At Fri, 27 Nov 2009 16:08:54 +0100,
Stefan Santesson wrote:
> 
> No I don't have any scenario (and I said so).
> 
> This was part of a principal (theoretical) argument.

As Nikos says, I don't see how this argument has any force:

The basic design of TLS rehandshaking is that it's performed 
over the same channel as the original handshake. Therefore, by
definition the attacker already has the contents of the immediately
previous Finished.

-Ekr


> On 09-11-27 3:30 PM, "Nikos Mavrogiannopoulos" <nmav@gnutls.org> wrote:
> 
> > On Thu, Nov 26, 2009 at 10:28 AM, Stefan Santesson <stefan@aaa-sec.com> wrote:
> > 
> >> On the contrary, I find it to be good security design not to exchange that
> >> value as it:
> >> 
> >> 1) Reduce information leakage to an attacker
> > 
> > Hello,
> >  How would that be? What scenario do you have in mind? This value has
> > already been exchanged in the initial finished message exchange and
> > was protected under the same ciphersuite. Why would this exchange be
> > less secure? If the attacker can decrypt and see this value, then he
> > can also see the initial finished value. No new information is given
> > to him.
> > 
> > 
> > regards,
> > Nikos
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls