Re: [TLS] Summarizing identity change discussion so far

Marsh Ray <marsh@extendedsubset.com> Tue, 08 December 2009 16:02 UTC

Return-Path: <marsh@extendedsubset.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 BBFF028C168 for <tls@core3.amsl.com>; Tue, 8 Dec 2009 08:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level:
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599]
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 obJN85G6-XEt for <tls@core3.amsl.com>; Tue, 8 Dec 2009 08:02:01 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D5B1928C152 for <tls@ietf.org>; Tue, 8 Dec 2009 08:02:00 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NI2VZ-000Gew-Tm; Tue, 08 Dec 2009 16:01:50 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F0616603A; Tue, 8 Dec 2009 16:01:47 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18ePzT2XGPoN0Gf6CqMmIW09MkQV2XF01c=
Message-ID: <4B1E786A.7070100@extendedsubset.com>
Date: Tue, 08 Dec 2009 10:01:46 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Pasi.Eronen@nokia.com
References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@cs.tcd.ie> <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Summarizing identity change discussion so far
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, 08 Dec 2009 16:02:01 -0000

Pasi.Eronen@nokia.com wrote:
> The security considerations section of this draft has to describe the
> fact that even with this fix, renegotiation does things that will
> surprise application developers,

Does it? This fix ensures that the same party is on each end for the
entire connection.

This rules out a MitM switching connections around. So the only
remaining issues must involve a client or server being able to switch
between certificates that he actually does have the private key for.
Clients are already expected to validate the server cert for any protection.

My impression is that the most surprising thing about renegotiation for
most app developers is that it can happen at all, and that their TLS
library may be silently handling it by default. If we make any
recommendations for TLS libraries it should be to not do renegotiation
unless the application asks for it by registering a callback.

> and can cause security
> vulnerabilities for some of them.

Do we know of any examples? I can only think of some very subtle and
hypothetical ones that require client and server apps that are already
coded for switching identities intentionally.

> That part we cannot avoid -- some text has to be included.
> 
> It's not absolutely required that the text makes recommendations how
> to avoid those vulnerabilities, but IMHO it would be a bit strange to
> just describe the security problem without saying anything how to
> avoid it...

Any security problems which remain after MitM renegotiation is fixed
will be interesting to research, but I just don't think we understand
them well enough yet to describe them in an official document.

- Marsh