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