Re: [TLS] Chatter on consensus
"Kemp, David P." <DPKemp@missi.ncsc.mil> Wed, 27 January 2010 19:12 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 4AAF73A6918 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 11:12:52 -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 0ktNCvLplOza for <tls@core3.amsl.com>; Wed, 27 Jan 2010 11:12:48 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id B29D93A67F4 for <tls@ietf.org>; Wed, 27 Jan 2010 11:12:47 -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: Wed, 27 Jan 2010 14:13:00 -0500
Message-ID: <201001271913.o0RJD2B7008022@stingray.missi.ncsc.mil>
In-Reply-To: <201001271509.o0RF97fO015438@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Chatter on consensus
thread-index: AcqfYskC8bgaAXanTqePrOQM5pt83wAAIsQA
References: <201001271440.o0REeTJU015911@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 27, 10 09:39:34 am <201001271509.o0RF97fO015438@fs4113.wdf.sap.corp>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: mrex@sap.com
X-OriginalArrivalTime: 27 Jan 2010 19:13:38.0390 (UTC) FILETIME=[D48B9F60:01CA9F84]
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: Wed, 27 Jan 2010 19:12:53 -0000
> From: Martin Rex [mailto:mrex@sap.com] > > These two MUST NOTs and the two unexplained NOT RECOMMENDEDs > to which I'm opposed are clear violations of rfc-2119 section 6: This is admittedly a strong argument. However, in my opinion, alignment with 2119 must be evaluated in light of: > [Nikos]: I believe allowing the sending of both SCSV > and extension might harm interoperability instead. and > [Pettersen]: The SCSV is a temporary fallback, one that > will not be needed when clients enter strict mode, since > when that happens servers have to support the RI extension. When the reality of development practices is taken into account, the MUST NOTs arguably *are* being used to enhance interoperability, in accordance with rfc-2119. > From: Martin Rex [mailto:mrex@sap.com] > > It more complicated than that, because SCSV is additionally > necessary for sensible behaviour even with -03 when doing > old renegotiation on a connection where the initial > ClientHello did not use any TLS extensions. Say whaaaaat? When doing old renegotiation, neither SCSV nor RI are necessary because by assumption the client, the server, or both do not support secure renegotiation. If an old server requests a new client to renegotiate, and: 1) the client ignores the RECOMMENDED refusal to renegotiate, and 2) the old server INCORRECTLY fails to ignore extensions, and 3) the client sends an RI extension as RECOMMENDED, ... then there may be a handshake failure, which sounds to me like the desired outcome in such a broken circumstance. If the client instead sends SCSV in order to dodge a handshake failure, which is NOT RECOMMENDED, the server is prevented from immediately detecting an attack. Sending SCSV in this circumstance, far from being necessary or sensible, sounds to me like reckless behavior - pushing the envelope of legacy interoperability. As above, it might enhance interoperability long-term if new clients operating in secure renegotiation mode simply failed to renegotiate with broken servers. If I were for changes to -03 (which I am NOT!), it would be to change NOT RECOMMENDED to MUST NOT send SCSV in insecure renegotiation. Dave
- 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)