Re: [TLS] draft-rescorla-tls-renegotiate.txt

Martin Rex <mrex@sap.com> Sat, 07 November 2009 00:39 UTC

Return-Path: <mrex@sap.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 3DB173A6A83 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 16:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.121
X-Spam-Level:
X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Y69D-GUkhEq2 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 16:39:43 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3D0F03A6824 for <tls@ietf.org>; Fri, 6 Nov 2009 16:39:43 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA70e5aI016543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 01:40:05 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911070040.nA70e4oH017413@fs4113.wdf.sap.corp>
To: rrelyea@redhat.com (Robert Relyea)
Date: Sat, 7 Nov 2009 01:40:04 +0100 (MET)
In-Reply-To: <4AF497C5.5060801@REDHAT.COM> from "Robert Relyea" at Nov 6, 9 01:40:21 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Sat, 07 Nov 2009 00:39:44 -0000

Robert Relyea wrote:
> 
> >> Even more importantly, SSLv3 does not support extensions.
> >>     
> > You're correct.  SSLv3 allows extensions in the ClientHello that
> > are to be ignored, but it does not support them in ServerHello.
>   
> In practice, there are too many servers that blow up even on extensions
> in clientHellos. So many that NSS only uses extensions in TLS, not in SSL3.

I have no data and no experiences about interop issues with >SSLv3.

Networking or multimedia appliances might be the hardest to get
upgraded, although they're quite unlikely themselves to use
client-cert authentication, much less through renegotiation.

We shouldn't unnecessarily create interop-problems with them
(or force them to drop to plain http).


What exactly do you mean by "only uses extensions in TLS"?

TLS extensions must be asserted in the ClientHello, and a SSLv3 server
is expected to ignore them.


Are you rather referring to fallback/reconnect-heuristics in Browsers
that will automatically re-try a failed TLS-handshake with TLS extensions 
by a SSLv3 handshake without TLS extensions.  Which Browsers&Versions
do that, actually (I simply don't know)?

Such a fallback would certainly help, but is entirely an apps issue.
It is much less likely to be present in programmatic clients, I assume.


-Martin