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

Martin Rex <mrex@sap.com> Wed, 16 December 2009 20:59 UTC

Return-Path: <mrex@sap.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 457CE3A6A03 for <tls@core3.amsl.com>; Wed, 16 Dec 2009 12:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 yB9fHO3VG5zr for <tls@core3.amsl.com>; Wed, 16 Dec 2009 12:59:23 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 45E833A67EC for <tls@ietf.org>; Wed, 16 Dec 2009 12:59:23 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGKx7Vj007080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 21:59:07 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp>
To: DPKemp@missi.ncsc.mil
Date: Wed, 16 Dec 2009 21:59:07 +0100
In-Reply-To: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> from "Kemp, David P." at Dec 16, 9 03:00:39 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 16 Dec 2009 20:59:24 -0000

Kemp, David P. wrote:
> 
> Martin's text contradicts the AD's decision ...

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.

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.

So as far as rough consensus is concerned, it is definitely
with the approach I described.  This is what the IETF procedures
are about.  Otherwise we could just go back to counting votes.

-Martin