Re: [TLS] Confirming consensus about one
"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 26 January 2010 22:51 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 F2A153A69EF; Tue, 26 Jan 2010 14:51:21 -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=[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 219Q1mIuO+zw; Tue, 26 Jan 2010 14:51:21 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id F1FC33A6928; Tue, 26 Jan 2010 14:51:20 -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: Tue, 26 Jan 2010 17:50:23 -0500
Message-ID: <201001262251.o0QMpJMf020349@stingray.missi.ncsc.mil>
In-Reply-To: <201001262143.o0QLhWA6009324@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Confirming consensus about one
thread-index: Acqe0LoInseLs09gTeuxwylZVaOjJwAAIGUw
References: <201001261530.o0QFUxAT014069@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 26, 10 10:30:20 am <201001262143.o0QLhWA6009324@fs4113.wdf.sap.corp>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: mrex@sap.com
X-OriginalArrivalTime: 26 Jan 2010 22:51:55.0515 (UTC) FILETIME=[28A08CB0:01CA9EDA]
Cc: tls@ietf.org, ietf@ietf.org
Subject: Re: [TLS] Confirming consensus about one
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: Tue, 26 Jan 2010 22:51:22 -0000
Yes. I agree that SCSV could be defined to convey only 1 bit of information while RI conveys 2 bits, and agree that -01 (which went through last call) does not define it that way. What I don't understand is why the issue of changing the semantics of -01 and -03 to reflect a "1 bit SCSV" is so #$%& important. 1. It is trivially easy to code to either version. 2. There is no security impact of using either version. 3. It is easier to articulate and to understand an "identical" soundbite than to explain how SCSV and empty RI are semantically different, and 4. The "identical" version is ready to go, in the form of -03 that can be published as an RFC right now. And although I hesitate to bring up the following since they are non-essential, 5. SCSV is a hack meant to appease ancient and/or non-conforming servers. That is one ugly baby, and I wish it would just disappear. There is absolutely no reason for it ever to be sent in a ClientHello containing a non-empty RI (it is a no-op that just wastes N bits of bandwidth to convey 0 bits of additional information, and no legacy implementation would ever send or interpret it), so I see absolutely no downside to prohibiting it during renegotiation. 6. Reducing optional elements is always good security hygiene (hash collision space, covert channels, stack overflow alignment, etc.) Take away a useless knob and nobody can twiddle that knob against you. Dave -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] Sent: Tuesday, January 26, 2010 4:44 PM To: Kemp, David P. Cc: tls@ietf.org; ietf@ietf.org Subject: Re: [TLS] Confirming consensus about one Kemp, David P. wrote: > > Rationale: > > Version -01 states that the semantics of SCSV is identical to the > semantics an empty RI, namely: "this client is capable of supporting > secure renegotiation, and this ClientHello message is an initial > handshake, not a renegotiation handshake." But you do realize that we discussed this issue on the WG mailing list and the I provided an explanation along the lines of a semi-formal correctness proof that this rationale is based on a misunderstanding and a poor choice of words in the specification. http://www.ietf.org/mail-archive/web/tls/current/msg05466.html -Martin
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- [TLS] Confirming consensus about one draft-ietf-t… Pasi.Eronen
- Re: [TLS] Confirming consensus about one draft-ie… Robert Dugal
- Re: [TLS] Confirming consensus about one draft-ie… Dr Stephen Henson
- Re: [TLS] Confirming consensus about one draft-ie… Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Michael D'Errico
- Re: [TLS] Confirming consensus about one draft-ie… Rex, Martin
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- [TLS] Metadiscussion on changes in draft-ietf-tls… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Marsh Ray
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Hovav Shacham
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Confirming consensus about one draft-ie… Yngve Nysaeter Pettersen
- [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Nelson B Bolyard
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Bob Braden
- Re: [TLS] Confirming consensus about one Michael D'Errico
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Marsh Ray
- Re: [TLS] Confirming consensus about one draft-ie… Robert Relyea
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Paul Hoffman
- [TLS] interoperability and security guarantees [w… Daniel Kahn Gillmor
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Michael D'Errico
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Nikos Mavrogiannopoulos
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Bill Frantz
- Re: [TLS] Confirming consensus about one draft-ie… tom.petch
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)