Re: [TLS] Last Call: draft-ietf-tls-renegotiation - deployment in

Marsh Ray <marsh@extendedsubset.com> Sun, 06 December 2009 04:19 UTC

Return-Path: <marsh@extendedsubset.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 85CE43A68D3 for <tls@core3.amsl.com>; Sat, 5 Dec 2009 20:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 RWIsPUFqBoOb for <tls@core3.amsl.com>; Sat, 5 Dec 2009 20:19:32 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 874BD3A684A for <tls@ietf.org>; Sat, 5 Dec 2009 20:19:32 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NH8ag-000F5q-Ry; Sun, 06 Dec 2009 04:19:22 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A219B6678; Sun, 6 Dec 2009 04:19:20 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1949MJwWSvV49l2ewGwPFEsWKXyl43o1ls=
Message-ID: <4B1B30C6.2080906@extendedsubset.com>
Date: Sat, 05 Dec 2009 22:19:18 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <200912060324.nB63O3ll023763@fs4113.wdf.sap.corp>
In-Reply-To: <200912060324.nB63O3ll023763@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation - deployment in
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: Sun, 06 Dec 2009 04:19:33 -0000

(The quoting got too much for me, check archives for thread context.)

The language in the TLS 1.0 and 1.1 specs is something like:

> TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
> supporting both is easy.  TLS clients who wish to negotiate with such
> older servers SHOULD ...

Notice the conditional SHOULD there. It seems to support the view that
successful negotiation with an SSLv3 server (especially a broken one)
is not considered a MUST for a conformant TLS implementation.

What if we adapt the proposed language thusly:

Clients that wish to be compatible with the maximum number of older
servers (including SSLv3 servers not supporting TLS), SHOULD signal
using the special TLS cipher suite value rather than including an
extension on the initial Client Hello. (Note that this does not apply to
any subsequent Client Hello messages sent.) Any such client MUST be
prepared to receive in response a Server Hello message of any negotiable
version (subject to the usual rules) which contains the extension.
Clients are not required to offer support back to SSLv3, but if they do,
they MUST implement the behaviors described in this specification.

- Marsh