Re: [TLS] Chatter on consensus

"Kemp, David P." <DPKemp@missi.ncsc.mil> Thu, 28 January 2010 14:55 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 8EE613A690F for <tls@core3.amsl.com>; Thu, 28 Jan 2010 06:55:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Atx0P7jMXyCY for <tls@core3.amsl.com>; Thu, 28 Jan 2010 06:55:01 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id A93813A67BD for <tls@ietf.org>; Thu, 28 Jan 2010 06:55:01 -0800 (PST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 28 Jan 2010 09:55:16 -0500
Message-ID: <201001281455.o0SEtHXW017914@stingray.missi.ncsc.mil>
In-Reply-To: <201001280054.o0S0sbjo022469@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Chatter on consensus
thread-index: AcqftKnZjbC14gQhTMqYGqSPqkoyQgAcaNDA
References: <201001272306.o0RN6xOx027395@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 27, 10 06:06:58 pm <201001280054.o0S0sbjo022469@fs4113.wdf.sap.corp>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <mrex@sap.com>
X-OriginalArrivalTime: 28 Jan 2010 14:55:54.0531 (UTC) FILETIME=[FDC7BF30:01CAA029]
Cc: tls@ietf.org
Subject: Re: [TLS] Chatter on consensus
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, 28 Jan 2010 14:55:02 -0000

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]

The MUST NOTs and the NOT RECOMMENDEDs I'm objecting to are
completely invisible at both, the API level and in the policy
configuration
that determines which kind of interoperability should be allowed.

-----End-----


But they must not be invisible to you, as a code author, since you are
objecting to the lack of freedom to do things in different ways that are
visible outside the implementation.

And they are not invisible to someone examining bits on the wire,
because if they wished to color flows, they could distinguish
implementation A from implementations B, C, and D based on whether Hello
messages contained SCSV, RI, both, or neither.  There would be fewer
colors if -03 said SCSV MUST NOT be sent under any circumstances, or if
Michael's UseExtensions option was set.

It's been an interesting discussion, but I'm in most people's kill files
by now so I'll shut up.

Regards,
Dave