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

Stefan Santesson <stefan@aaa-sec.com> Mon, 30 November 2009 07:12 UTC

Return-Path: <stefan@aaa-sec.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 612153A6855 for <tls@core3.amsl.com>; Sun, 29 Nov 2009 23:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level:
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 Ii+cWybI0lrF for <tls@core3.amsl.com>; Sun, 29 Nov 2009 23:12:21 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id DA4633A67E5 for <tls@ietf.org>; Sun, 29 Nov 2009 23:12:20 -0800 (PST)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0D1FD290201 for <tls@ietf.org>; Mon, 30 Nov 2009 08:11:11 +0100 (CET)
Received: (qmail 27486 invoked from network); 30 Nov 2009 07:11:09 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <marsh@extendedsubset.com>; 30 Nov 2009 07:11:09 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 30 Nov 2009 08:11:07 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <C7392E9B.6C9A%stefan@aaa-sec.com>
Thread-Topic: [TLS] Verify data in the RI extension?
Thread-Index: AcpxjEkkCD9RKdjXHUuj7LRC360noQ==
In-Reply-To: <4B130E65.4000009@extendedsubset.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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: Mon, 30 Nov 2009 07:12:25 -0000

On 09-11-30 1:14 AM, "Marsh Ray" <marsh@extendedsubset.com> wrote:

> Stefan Santesson wrote:
>> 
>> The real security advantage of implicit is that you know that the opponent
> 
> I agree that is possibly an advantage, but a very weak advantage.
> 

Well, It's not weak or strong in a cryptographic sense. The weakness is
totally dependent on whether implementers get this right or not. The problem
is that you can't tell whether they did since it doesn't show.
If they get it right, there is no weakness, if some or any get it wrong, it
may significantly reduce the value of this effort.

With implicit, implementers can't get it wrong and still produce a valid
finished message.

I personally think this is a significant advantage.

>> actually derived the same value from previous handshake. By sending it in RI
>> you don't know if the opponent just blindly accepted what you sent without
>> checking it. 
> 
> By that logic, how do you know that he's checking the Finished message hash?
> 

That you never know, but he wouldn't be able to produce a valid Finished
message unless he derived the accurate data from the previous handshake.

/Stefan

> - Marsh