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

Stefan Santesson <stefan@aaa-sec.com> Fri, 27 November 2009 15:00 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 F418A3A6894 for <tls@core3.amsl.com>; Fri, 27 Nov 2009 07:00:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level:
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 9SUZ1aGgo3op for <tls@core3.amsl.com>; Fri, 27 Nov 2009 07:00:49 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 1295B3A6887 for <tls@ietf.org>; Fri, 27 Nov 2009 07:00:47 -0800 (PST)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6B9E728BD90 for <tls@ietf.org>; Fri, 27 Nov 2009 16:00:45 +0100 (CET)
Received: (qmail 26712 invoked from network); 27 Nov 2009 15:00:39 -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 s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <Pasi.Eronen@nokia.com>; 27 Nov 2009 15:00:39 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 27 Nov 2009 16:00:38 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Pasi.Eronen@nokia.com, ynir@checkpoint.com
Message-ID: <C735A826.6BDA%stefan@aaa-sec.com>
Thread-Topic: [TLS] Verify data in the RI extension?
Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpzAAB4MmAAAeg4SwAIKiIwAAI9Tak=
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.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: Fri, 27 Nov 2009 15:00:50 -0000

Pasi,

On 09-11-27 3:09 PM, "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com> wrote:

> For simplicity, the current draft is already very simple, and IMHO
> it's not clear that continuing to tweak it has a positive return
> on investment, considering it delays the publication.

It's not a matter of tweaking,

This working group discussion has produced 2 proposals.

If you count in changes that is about to be applied to Marin's document the
following apply:

1) Both proposals agree on the same initial signaling (cipher suite for C->S
and empty RI for S->C)

2) For renegotiations:
   a) Martin's draft propose to update (fix) the Finished calculation
      and use the same signaling as in 1).
   b) Eric's draft suggest sending verify_data in RI extensions and keep the
      old Finished calculation.

Many members of this list argue that 2a has better security properties and
is simpler to deploy (especially for legacy implementations).
The arguments for 2b seems to be that it is "good enough" and "why should we
care about old legacy implementations".

Now, maybe I'm wrong about that, but wouldn't it at least be fair to ask the
working group which approach they prefer?

/Stefan