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

Martin Rex <mrex@sap.com> Fri, 06 November 2009 23:53 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 A698D3A690F for <tls@core3.amsl.com>; Fri, 6 Nov 2009 15:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.105
X-Spam-Level:
X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 AKY32Lc9A9WZ for <tls@core3.amsl.com>; Fri, 6 Nov 2009 15:53:25 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 79ADB3A6898 for <tls@ietf.org>; Fri, 6 Nov 2009 15:53:25 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA6Nrlr7019081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 00:53:47 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911062353.nA6NrkWu014870@fs4113.wdf.sap.corp>
To: noskov@microsoft.com
Date: Sat, 07 Nov 2009 00:53:46 +0100
In-Reply-To: <B197003731D4874CA41DE7B446BBA3E829CA5315@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> from "Nasko Oskov" at Nov 6, 9 08:38:13 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org, Nicolas.Williams@sun.com
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: Fri, 06 Nov 2009 23:53:26 -0000

Nicolas Williams wrote:
> 
> Stop using SSLv3.  Its end has arrived.

I was actually looking for an answer from engineering,
not for one from sales.  :-|


We might need to ask a few hundred million users to enable TLS 1.0
on their MSIE browsers running on Windows XP.

And you really should not underestimate the amount of software
where it needs much more that a registry key to obtain TLS support.


The answer might not be as simple as saying "drop SSLv3 support".


Nasko Oskov wrote:
> 
> Dare I say block renegotiations in SSLv3? Most implementations
> have had TLS1.0 support for a long time, so compatibility
> impact should be fairly low.

That misses the point somewhat.  There are several aspects
that need to be addressed.


*I* do not have a problem with requiring servers that want to continue
using renegotiation to upgrade to at least TLSv1.0.  I think that
is doable.

But what are we going to require from Servers that use the delayed
authentication through renegotiation, and want to continue using it
when SSLv3 clients connect (either stuck at or configured for SSLv3 only)?

I think we ought to require them to refuse traditional renegotiation
in the future (what should they send back to v3.0 clients trying)?

They could send a CertificateRequest to v3 clients in the initial
full handshake instead (causing a slightly different "user experience"
to TLSv1.x clients with delayed authentication).  I would like to
require them to do that (if they support client-cert authentication)
but I do not think we can do that, and I have no idea how difficult
that would be for the various servers to implement.


But all that doesn't give the clients the possibility to protect
themselves from the MITM attack (that what is described in
the client considerations of Eric's proposal).


It leaves an extremely bad taste if we push people with software
that is not vulnerable in order to protect against a vulerability
of a number of broken servers with whom they're not affiliated.


What would you think if suddenly someone in your street would
get himself a very dangerous, huge and badly tempered dog and
he would let him outside regularly -- with no fence and no leash
and the other 12 neighbours in the street would have to put up
fences around their property to protect from that dog.

IMHO, the guy with the dog should be required to either
build a fence around his property, put the dog on a leash or chain
or get rid of it.


If we agree on a fix to this problem in TLS, and the deployment
results in interoperability problems that can _not_ be easily fixed
(and it is naive to assume there will not be any, the installed
 base is so awfully large), then the wording of our specification
and requirements may make a difference on who will have to change
what based on contractual obligations. (IANAL though)

And personally, I think that neither "Your SSLv3 client is to old"
nor "get the update for your TLSv1.0 client" is a justified
position, because in most cases it is purely a problem of the server.


There also is a much higher likelyhood of servers being under
maintenance (support contract), than clients.


-Martin