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