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

<Pasi.Eronen@nokia.com> Fri, 27 November 2009 14:10 UTC

Return-Path: <Pasi.Eronen@nokia.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 C77653A68C8 for <tls@core3.amsl.com>; Fri, 27 Nov 2009 06:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.503
X-Spam-Level:
X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 xz8bWSrfWSc4 for <tls@core3.amsl.com>; Fri, 27 Nov 2009 06:10:35 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 203863A6839 for <tls@ietf.org>; Fri, 27 Nov 2009 06:10:34 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nARE9njt003916; Fri, 27 Nov 2009 16:10:11 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 16:10:05 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 16:10:00 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 27 Nov 2009 15:09:59 +0100
From: Pasi.Eronen@nokia.com
To: stefan@aaa-sec.com, ynir@checkpoint.com
Date: Fri, 27 Nov 2009 15:09:58 +0100
Thread-Topic: [TLS] Verify data in the RI extension?
Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpzAAB4MmAAAeg4SwAIKiIw
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F3113EBBB@NOK-EUMSG-01.mgdnok.nokia.com> <C7356254.6BBB%stefan@aaa-sec.com>
In-Reply-To: <C7356254.6BBB%stefan@aaa-sec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Nov 2009 14:10:00.0301 (UTC) FILETIME=[4E8519D0:01CA6F6B]
X-Nokia-AV: Clean
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 14:10:38 -0000

Stefan Santesson wrote:

> Well, I don't bring this up just because it would be a bit nicer.
> 
> I bring this up since NOT exchanging verify_data seems to offer:
> 
> 1) better security
> 2) simplicity - allows the signaling to be identical for all handshake
> exchanges regardless of protocol version.
> 3) better compatibility/easier migration towards future versions of TLS

IMHO all these are your opinions, not facts (in some cases, my personal
opinion could be the same as yours, though -- but that doesn't mean
everyone else agrees, too).

This *might* bring better security if you assume implementors that are
stupid in a very particular way. But if they're stupid in some other
way, there's necessarily no difference. And seriously speaking, the 
current draft is so simple that if an implementor can't get it right,
he/she has no business in implementing security-critical components...

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. 

About future versions of TLS, IMHO it's quite difficult to predict which
would be most compatible. What if, e.g., the next version of TLS
decides that sending certificates in the clear wasn't that great idea,
and nowadays we can afford to do Diffie-Hellman before doing any
authentication? This could completely change all the handshake
messages after ClientHello, and the current functionality of "Finished"
could be done in quite different way.. 

(I'm not suggesting that TLS 1.3/2.0 should do that -- just that
we don't know what it will do yet.) 

Best regards,
Pasi
(not wearing any hats)