Re: [TLS] Chatter on consensus
Michael D'Errico <mike-list@pobox.com> Wed, 27 January 2010 23:36 UTC
Return-Path: <mike-list@pobox.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 2E8023A69F6 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 15:36:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 XrUD+jOJnVUa for <tls@core3.amsl.com>; Wed, 27 Jan 2010 15:36:41 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 16D623A69E0 for <tls@ietf.org>; Wed, 27 Jan 2010 15:36:41 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 72B249400E for <tls@ietf.org>; Wed, 27 Jan 2010 18:36:56 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=5wJUDzoH0n1e QMpQU+96ruS3kfg=; b=DMwFJ2gb12b6RZplJS11USNMvpTk/KRHn0QMpUbaliKb UVUrE8hkrp+Gut+oI7S17P9ITlZlQGtBKYWGuAoZFEYCBSuUgbYjTrWBvBcC1Ews k3HCtMmLlOHF9HcHi3AbVbfI26m3reU2ePWUmuUoZIanOZCW+bdu2xb0pjgmLNY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=JxR4e3 /q6x31pAHzzAhx0VDIMbKj3vreSaMj3WKBjPKaAr5jE0OJKRHzkWieluLFqv+h1i 0/MUQ0ZSmSYgWBxVdfEVCzxUjaHV02CsRadBrzSI33fWA8wzWEdDj622T1PJ69V0 CUhDbBq+hH5snoBIdcoDIy+NUyjWppTQ4c3VE=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6EDAD9400D for <tls@ietf.org>; Wed, 27 Jan 2010 18:36:56 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 060849400C for <tls@ietf.org>; Wed, 27 Jan 2010 18:36:55 -0500 (EST)
Message-ID: <4B60CECD.50508@pobox.com>
Date: Wed, 27 Jan 2010 15:39:57 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
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> <201001272306.o0RN6xOx027395@stingray.missi.ncsc.mil>
In-Reply-To: <201001272306.o0RN6xOx027395@stingray.missi.ncsc.mil>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: DB2B1948-0B9C-11DF-A69E-6AF7ED7EF46B-38729857!a-pb-sasl-quonix.pobox.com
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:36:42 -0000
Kemp, David P. wrote: > 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? I have one other related client option: UseExtensions. If it is false, then SCSV is sent instead of RI. If a renegotiation happens, an RI is sent even though UseExtensions is false (though no others are sent). These 4 bits seem to be enough to fully control renegotiation without moving to a callback-style interface. Mike > 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
- 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)