Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 12 January 2010 18:23 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 27B603A6911 for <tls@core3.amsl.com>; Tue, 12 Jan 2010 10:23:40 -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 dWOYT3Oy71a5 for <tls@core3.amsl.com>; Tue, 12 Jan 2010 10:23:39 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 0858D3A6A6F for <tls@ietf.org>; Tue, 12 Jan 2010 10:23:38 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Jan 2010 13:23:35 -0500
Message-ID: <201001121823.o0CINZp3023343@stingray.missi.ncsc.mil>
In-Reply-To: <201001121640.o0CGedKe007515@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft
Thread-Index: AcqTph0cnZpZp6m2R1mOmqS0HxWd7gAAJYUQ
References: <201001121543.o0CFhYuI011143@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 12, 10 10:43:33 am <201001121640.o0CGedKe007515@fs4113.wdf.sap.corp>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <tls@ietf.org>
X-OriginalArrivalTime: 12 Jan 2010 18:24:07.0078 (UTC) FILETIME=[6D4F2460:01CA93B4]
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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: Tue, 12 Jan 2010 18:23:40 -0000

That is simply a terminology issue.  Whether you call TLSv1.1 (without
renegotiation protection) and TLSv1.1p (with protection) different
protocols or the same protocol with different features, the point
is that the UI must have a separate checkbox for the version/feature.
The fact that there will be a new RFC and that it assigns a new minor
version number influenced my terminology, but it is fine to regard
the "p" as a feature instead.

If only "p" versions are checked or if the "p" feature is checked
(depending on which way the UI is designed), then an RFC-WXYZ-compliant
endpoint MUST either abort any connection with partners that do
not support protection or it MUST disable its own support for
renegotiation.

This is no different than ciphersuites - if your policy is to
require AES encryption, then you would demand that the partner
also support AES or you would refuse to connect.  If your policy is
that single DES is good enough, then you will check both the DES
and AES boxes and communication with DES-only installed-base
partners is possible.

Dave

(To head off other red herrings, the UI checkbox is just
an example - obviously policy may be expressed using header files,
config files, registry settings, or otherwise.)



-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com] 

> 
> That is not a policy decision embedded in protocol, it is a
> truth in advertising requirement.  If a client's or server's
> policy is that communication is more important than resistance
> to renegotiation attack, than that policy is expressed by accepting
> connections using the SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
> protocols.

A TLS client or TLS server that does _not_ interoperate with an old
TLS implementation on the initial handshake is simply not compliant
to whatever protocol (SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2) is
negotiated.

The new specification about (secure) TLS renegotiation _only_
deprecates an optional feature of the existing protocol and
adds a new optional feature for them.  This spec does _NOT_
change the core protocol.  Otherwise it would not be an
update, but a new protocol.


-Martin