Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

Martin Rex <mrex@sap.com> Tue, 10 November 2009 20:34 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 6B2F63A68E7 for <tls@core3.amsl.com>; Tue, 10 Nov 2009 12:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.159
X-Spam-Level:
X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 6BGVuJEuGhI4 for <tls@core3.amsl.com>; Tue, 10 Nov 2009 12:34:46 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C830C3A67E4 for <tls@ietf.org>; Tue, 10 Nov 2009 12:34:21 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAAKYkvZ027150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 21:34:46 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911102034.nAAKYjkA023781@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Tue, 10 Nov 2009 21:34:45 +0100
In-Reply-To: <4AF8E755.5020208@extendedsubset.com> from "Marsh Ray" at Nov 9, 9 10:08:53 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 and MITM resistance
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: Tue, 10 Nov 2009 20:34:47 -0000

Marsh Ray wrote:
> 
> Nicolas Williams wrote:
> > On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote:
> >> I whish there was a constraint that an identity/certificate that has
> >> been established for a party during the TLS handshake MUST not change
> >> during re-negotiation,
> 
> Hmm, few questions about that plan:
> 
> Is this currently a defined concept in TLS: equivalence of identity?

blob_compare(current-cert-blob,new-cert-blob)

Everything more complicated should be an apps issue--provided that
the apps has provided "convincing arguments" to the TLS implementation
(i.e. correctly instrumented the relevant APIs)
that it is competent to perform such a re-authentication as a result
of an identity change during renegotiation.

> 
> Isn't that one of the major uses of renegotiation? To change identity?

I simply don't know.  Our server doesn't support renegotiation.
And I learned our client to do it several years ago since it was
used in certain configurations of MS IIS to ask for a client
certificate after having seen the request.


>
> That seems to be the entire point of the observed cases of renegotiation
> in https. Even if the only case we know of is a transition from an
> anonymous identity to a client-certified one, such a new constraint
> seems a bit pointless and likely to break someone.

This might not accurately describe the situation you have in mind.

A client that has not sent a certificate (usually because the server
didn't send a CertificateRequest) is definitely not an "established
anonymous identity".  It is simply the absence of an identity.

The use of a DH_anon ciphersuite, on the other hand, might be considered
to establish an anonymous identity for the server.  I do not like the
DH_anon ciphersuites and I'm wondering what TLS implementations do
that provide applications a callback for verification of the server
cert which is usually called while processing the ServerCertificate
handshake message when the server selects a DH_anon ciphersuite
(in which case there is no ServerCertificate handshake message).



-Martin