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