Re: [TLS] Chatter on consensus
"Kemp, David P." <DPKemp@missi.ncsc.mil> Wed, 27 January 2010 23:06 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 D245D3A69E9 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 15:06:44 -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 XRYoAlZO2Mml for <tls@core3.amsl.com>; Wed, 27 Jan 2010 15:06:44 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id CA3E23A635F for <tls@ietf.org>; Wed, 27 Jan 2010 15:06:43 -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 18:06:58 -0500
Message-ID: <201001272306.o0RN6xOx027395@stingray.missi.ncsc.mil>
In-Reply-To: <201001272102.o0RL2I9x007631@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Chatter on consensus
thread-index: AcqflCHxeKran32GSySJURB2sZ3aswAALzow
References: <201001271913.o0RJD2B7008022@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 27, 10 02:13:00 pm <201001272102.o0RL2I9x007631@fs4113.wdf.sap.corp>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 27 Jan 2010 23:07:35.0828 (UTC) FILETIME=[8382AD40:01CA9FA5]
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 23:06:44 -0000
Michael D'Errico's solution: > In my code, I added three boolean configuration > options which all default to false: > > AllowUnsafeInitialConnect > AllowRenegotiation > AllowUnsafeRenegotiation > > Hopefully this will make it obvious to people that > choosing the Unsafe options are just that (though > the first one will be needed for a while yet). ... sounds quite reasonable. But how many bits would it take to fully control how renegotiation is performed assuming that -03 permits everything (contains no MUSTs/MUST NOTs), and how many of those bits would any customers really want to have or understand how to use? default (all others false - renegotiation not allowed, sends neither SCSV nor RI) Secure_renegotiation flag is True: AllowRenegotiationUsingExtension (sends RI) (Section 3.5 required by elimination) AllowRenegotiationUsingBoth (sends SCSV and RI) (Section 3.5 MUST NOT) Secure_renegotiation flag is False: AllowUnsafeRenegotiationUsingSSLTLS (sends neither SCSV nor RI) (uses legacy specs) AllowUnsafeRenegotiationUsingExtension (sends RI) (Section 4.2 recommended by elimination) AllowUnsafeRenegotiationUsingCipherSuite (sends SCSV) (Section 4.2 NOT RECOMMENDED) AllowUnsafeRenegotiationUsingBoth (sends SCSV and RI) (Section 4.2 silent) For secure renegotiation, if you eliminate the MUST NOT in section 3.5, then you must add a configuration somewhere (either hard coded or as a configuration option) that determines how the software will behave. For insecure renegotiation, backwards interop scenarios can be supported non-disruptively in 3 different ways in accordance with -03, but they can also be supported non-disruptively in a 4th way, by following the RFCs for TLSv1.0-v1.2 and ignoring -03. As a customer, I don't really care about having 4 different ways of doing insecure renegotiation; I'd be just as happy using software that acts like a legacy application when it talks to other legacy applications, and where that legacy behavior can be turned off with a single switch when interop isn't needed. Dave -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] I do _not_ mind if you do not care for backwards interop scenarios, but I would recommend that you get out of the way of those who care because they must provide it to their customers in a non-disruptive fashion. -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)