Re: [TLS] draft-ietf-tls-renegotation: next

<Pasi.Eronen@nokia.com> Thu, 17 December 2009 11:31 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 7B3AE3A69D6 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 03:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 i2QJXIvW0vq0 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 03:31:26 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 544D53A6997 for <tls@ietf.org>; Thu, 17 Dec 2009 03:31:26 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBHBUeda006822; Thu, 17 Dec 2009 13:31:07 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 13:30:56 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 13:30:51 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 17 Dec 2009 12:30:51 +0100
From: Pasi.Eronen@nokia.com
To: mrex@sap.com
Date: Thu, 17 Dec 2009 12:30:49 +0100
Thread-Topic: [TLS] Re: draft-ietf-tls-renegotation: next
Thread-Index: Acp+kqHpKubfQdWgTq+wOKrcQt/lcAAd93uw
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com>
References: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> from "Kemp, David P." at Dec 16, 9 03:00:39 pm <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp>
In-Reply-To: <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp>
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: 17 Dec 2009 11:30:51.0942 (UTC) FILETIME=[63842460:01CA7F0C]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-renegotation: next
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: Thu, 17 Dec 2009 11:31:27 -0000

Martin Rex worte:

> I do not fully agree with the AD's determination of rough consensus.
> 
> For the MCSV signaling, the real rough consensus is different from
> what Pasi wrote:
> 
> http://www.ietf.org/mail-archive/web/tls/current/msg05306.html
> 
> A mandatory Client->Server signaling through cipher suite may
> have less fanatic followers by the count of numbers, but technical
> advantages and _no_ technical objections have been raised against it.

Several people have very clearly and strongly objected to making the
MSCV mandatory-to-include in ClientHello. You seem to be suggesting
that their opinions don't somehow matter because they are, in *your*
opinion, not "technical".

> The current either cipher suite or empty TLS extension RI signaling
> may have more "pro", but has significant objections against it
> because of the ambiguity, increased complexity, a 4x code size
> burden for old non-rengotiating servers and additional testing
> complexity.

If the specification text is ambiguous, we obviously need to fix that.

About the code/testing complexity/effort: I would say most people
believe that no matter what details get selected, this is not a
significant amount of work (so small differences in lines of code or
test cases should not signify much in making the decision).

> So as far as rough consensus is concerned, it is definitely with the
> approach I described.  

I disagree.

Best regards,
Pasi
(wearing Security Area Director hat)