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

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 10 November 2009 17:04 UTC

Return-Path: <Nicolas.Williams@sun.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 015A23A69C0 for <tls@core3.amsl.com>; Tue, 10 Nov 2009 09:04:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.016
X-Spam-Level:
X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 zMeJbSTIoktY for <tls@core3.amsl.com>; Tue, 10 Nov 2009 09:04:48 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 81D283A698D for <tls@ietf.org>; Tue, 10 Nov 2009 09:04:47 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAAH5D7k015700 for <tls@ietf.org>; Tue, 10 Nov 2009 17:05:14 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nAAH5DN7056810 for <tls@ietf.org>; Tue, 10 Nov 2009 10:05:13 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAAGkAqY012381; Tue, 10 Nov 2009 10:46:10 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAGk9i2012380; Tue, 10 Nov 2009 10:46:09 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 10 Nov 2009 10:46:09 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <20091110164609.GS1105@Sun.COM>
References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4AF8E755.5020208@extendedsubset.com>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org
Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
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: Tue, 10 Nov 2009 17:04:49 -0000

On Mon, Nov 09, 2009 at 10:08:53PM -0600, 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?

TLS connections are not so long lived that we should worry about issues
such as, for example, public key rollover or certificate expiration
during a connection's lifetime.  Therefore a simple Certificate octet-
for-octet comparison will do for identity comparison.  Anything more
complicated than that (and anon->non-anon) would make Martin's proposal
too unqieldy to consider at this point, and possibly ever.

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

But only from anonymous to non-anonymous, right?  That's also easy to
specify.

> Perhaps you want to allow identities to be "strengthened" but not
> "weakened". Is this another new concept in TLS: are identities required
> to be partially- or fully-ordered?
> 
> It's starting to sound like that question about ciphersuites being
> ordered according to strength.

No, I don't think so.  Ordering cipher suites by strength is a complex
topic that I'd rather avoid for the specific enhancement that Martin
proposes.

> Would that make it illegal to resume a previous session over the same
> underlying connection if it could not be proven it was "the same" identity?

There's no authentication during session resumption handshakes --
there's only proving that both peers remember the relevant state,
including master secret.

> What if the session's identity were strengthened? Could you end up in a
> situation where a session could be resumed on any of several other
> connections except the one on which it originated!

I'm not sure I follow.  See above.

Nico
--