Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
Nicolas Williams <Nicolas.Williams@sun.com> Tue, 10 November 2009 18:34 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 BAB4E3A6918 for <tls@core3.amsl.com>; Tue, 10 Nov 2009 10:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.022
X-Spam-Level:
X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.024, 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 5tENq-PhUHaW for <tls@core3.amsl.com>; Tue, 10 Nov 2009 10:34:22 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id AE8603A68EE for <tls@ietf.org>; Tue, 10 Nov 2009 10:34:22 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAAIYlkx009299 for <tls@ietf.org>; Tue, 10 Nov 2009 18:34:48 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 nAAIYlRf064705 for <tls@ietf.org>; Tue, 10 Nov 2009 11:34:47 -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 nAAIFjCA012571; Tue, 10 Nov 2009 12:15:45 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAIFjr9012570; Tue, 10 Nov 2009 12:15:45 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 10 Nov 2009 12:15:45 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <20091110181544.GW1105@Sun.COM>
References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com> <20091110164609.GS1105@Sun.COM> <4AF9AA9E.8030603@extendedsubset.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4AF9AA9E.8030603@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 18:34:23 -0000
On Tue, Nov 10, 2009 at 12:02:06PM -0600, Marsh Ray wrote: > Nicolas Williams wrote: > > On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote: > > > > TLS connections are not so long lived > > But there is no defined upper limit. True, and indeed, IMAP depends on that. Are there IMAP/other servers the request re-negotiation when a client's cert reaches/nears expiration? If so then my assertion that we don't have to worry about key rollover/ cert expiration would be wrong. Indeed, it's safer to assume that that assertion was wrong as finding out for sure would be hard. However, this is a constraint that _applications_ could enforce, or request be enforced by the TLS implementation (oh dear, back to APIs). > > that we should worry about issues > > such as, for example, public key rollover or certificate expiration > > during a connection's lifetime. > > I agree, but we should probably check that it's documented somewhere. It probably isn't. > > 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. > > So this restriction would not apply when another auth type is used? I suppose non-anon->anon re-negotiation, but with the new inner->outer connection binding should be OK once too (to allow for re-keying without having to bother with authentication). Yes, I see your point: this is now getting too complex. Applications can always enforce that identities don't change around re-negotiation, by asking the TLS implementation what the IDs were before and after re-negotiation, and by sticking to simple rules (e.g., cert octet-wise comparison) even if those defeat key/cert rollover. But if we're going to let apps do ths (and I think now only apps should) then there's no place in EKR's I-D for text about it, except, maybe, in the Security Considerations section (since TLS defines no APIs). > One subtlety is that apps (https servers) are still expecting the > transition to preserve some guarantees about identity. Even though the > first session is "anonymous" it still has an identity, namely it has to > be the same party as all previous non-anonymous sessions on the same > connection. > > The proposed Renegotiation Indication extension attempts to enforce > those guarantees, but I'm not sure it's so easy to specify that it > shouldn't be given a lot of thought. (Consider what happens when you add > various combinations of resumption into the mix.) Certainly channel binding is _always_ easier than identity equivalence. That's the main reason I have been pushing channel binding. There are a number of protocols where the only way to ensure there's no MITM is to ensure that one sees the same server identity on the server end of two channels -- that's asking for trouble. > > Ordering cipher suites by strength is a complex > > topic that I'd rather avoid for the specific enhancement that Martin > > proposes. > > Perhaps ordering levels of authentication is equally complex. If you're willing to make certain simplifying assumptions (e.g., no need for key/cert rollover), then authenticated ID equivalence can be simple. If you're not willing to make those assumptions then yes, it becomes as complex as cipher suite strength ordering. > Isn't proving "I'm the same as that other guy" a form of authentication? I.e., channel binding. It doesn't authenticate identities, but it does "authenticate" that two end-points are logically the same entity. > Surely this will be allowed: > > |--- session A anon ---||-- resumed A --| > > Is this allowed? I.e., negotiate an anonymous session, then re-negotiate where the re-negotiation is just a resumption of the anon session? Ick. > |--- session A anon ---| > |--- session B anon ---||-- resumed A --| > > I have heard that browsers may do this. I think session resumption in a re-negotiation should probably be out, yes. Nico --
- [TLS] draft-rescorla-tls-renegotiate and MITM res… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Dr Stephen Henson
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Steve Dispensa
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Peter Saint-Andre
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] To API or not Bill Frantz
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- [TLS] RC4+3DES rekeying - long-lived TLS connecti… Martin Rex
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… David-Sarah Hopwood
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… Peter Saint-Andre