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

Martin Rex <mrex@sap.com> Fri, 06 November 2009 19:56 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 E2B223A6859 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 11:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.085
X-Spam-Level:
X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.164, 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 dFk6QwuBjYfA for <tls@core3.amsl.com>; Fri, 6 Nov 2009 11:56:31 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 923103A67B6 for <tls@ietf.org>; Fri, 6 Nov 2009 11:56:31 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA6Jurvp019407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 20:56:53 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911061956.nA6JuqtB001719@fs4113.wdf.sap.corp>
To: mrex@sap.com
Date: Fri, 6 Nov 2009 20:56:52 +0100 (MET)
In-Reply-To: <200911061928.nA6JS7vq000076@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 6, 9 08:28:07 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: ekr@rtfm.com, 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: Fri, 06 Nov 2009 19:56:33 -0000

Martin Rex wrote:
> 
> It's not always an option to move to a newer implementation that
> also supports a more recent version of TLS, so I would appreciate
> that we describe two additional things in this draft:

While the things just described do not (necessarily) change the
proposed wire-protocol, they might change semantics and
interoperability of the protocol exchange with ongoing
implementations.  Making handshakes with attackers fail
earlier during the handshake is not my concern, of course.

But aside from this proposal, I was never really happy with
the performance impact of the delayed client auth, because
a TLS renegotiation alwas incurs a full TLS handshake.

There used to be (I have not checked lately) a particularly
bad user experience when connecting a firefox (2.x) to
MS IIS6 on W2K3 configured in directory-level access permissions
(i.e. the configuration that results in delayed TLS client auth
 through renegotiation).  When MS IIS6 was configured to allow
client-cert based authentication plus HTTP-authenticate:Negotiate
or basic-auth, but the firefox browser did not have a client
cert (or the user did not want to send it), then the bug in
the MS IIS6 server-side session cache resulted in a renegotiation
on every new connection, which resulted in a certificate selection
popup.  This could result in several popups per page if you
were browsing regular web-pages in protected areas rather
than plain directories.

What I would have appreciated, and what could prevent this
nonsense, is an extension that signals from the client to
the server "You do not need to try a CertificateRequest on me,
I will not send you a certificate!".  If a browsers memorizes
the uses decision (to not send a cert, or that there is no cert),
then it would really help if it could tell this to the SSL/TLS
server right away, instead of requiring the server to wonder
and probe this information with a full blown TLS handshake
through TLS renegotiate.


I do _not_ want to get any improvement in this area get into
the way of fixing the "secure renegotiation" issue.

Well only if the implementors/vendors that are most affected
by the security problem propose/agree that we could add
such signalling here (plus TLS WG consensus, of course).


-Martin