Re: [TLS] matching identity, by default

Bodo Moeller <bmoeller@acm.org> Tue, 12 January 2010 16:55 UTC

Return-Path: <SRS0=ep7a=I5=acm.org=bmoeller@srs.kundenserver.de>
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 F1F2428C0FB for <tls@core3.amsl.com>; Tue, 12 Jan 2010 08:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level:
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
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 Yokjha95mzHR for <tls@core3.amsl.com>; Tue, 12 Jan 2010 08:55:55 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id E3BE23A6A20 for <tls@ietf.org>; Tue, 12 Jan 2010 08:55:54 -0800 (PST)
Received: from dhcp-172-28-208-33.zrh.corp.google.com ([74.125.57.33]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MOmRO-1NYcBM0skQ-0063DN; Tue, 12 Jan 2010 17:55:43 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4B18096E.20805@extendedsubset.com>
References: <C2329F9D-F5EF-4E8B-9EE8-ED246D7B7287@manger.com.au> <BF782069-544A-4842-B8C8-A9472C9794BB@acm.org> <4B17C2F9.9010802@extendedsubset.com> <A1ECF717-4E06-4654-8B1D-7FDE6C5A2F24@acm.org> <4B18096E.20805@extendedsubset.com>
Message-Id: <CB10A859-5E2B-4B78-ABFB-1E045A6EFAFF@acm.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 12 Jan 2010 17:55:41 +0100
X-Mailer: Apple Mail (2.936)
X-Provags-ID: V01U2FsdGVkX19GZKqm7D2ejABKZcXZckbzCT7GUMlsUPecU75 VnJd4RMiGjF3ry++T27wokNN5lA0PyaUOR0nq+BRhzepQhpeP8 z+C8yXLKM4uWmNJwWFaRQ==
Cc: Nelson B Bolyard <nelson@bolyard.me>, "tls@ietf.org Working Group" <tls@ietf.org>, James Manger <james@manger.com.au>
Subject: Re: [TLS] matching identity, by default
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, 12 Jan 2010 17:05:19 -0000

On Dec 3, 2009, at 7:54 PM, Marsh Ray wrote:
> Bodo Moeller wrote:
>> On Dec 3, 2009, at 2:54 PM, Marsh Ray wrote:
>>> Bodo Moeller wrote:
>>
>>>> TLS has never meant to allow a new
>>>> client or server application entity to enter the conversation  
>>>> when a
>>>> renegotiation handshake takes place

>>> I disagree. The person(s) who added renegotiation clearly wanted to
>>> enable multiple "application entities" to run on the same port 443.

> [...]
> It certainly sounds to me like the spec intended to allow anything  
> that
> was valid in an initial negotiation to be valid in a renegotiation.

[...]
>>> These may be communicated over the same pool of active socket
>>> connections, as Nelson Bolyard of NSS (hier of the Netscape legacy
>>> implementation, twice removed) has described.

I think the disagreement here was more about how to *describe* what's  
happening in cases like these, not so much about their actual nature:

> "It is also possible that, in response to a client hello request, the
> client will send a client hello bearing a session ID that is not empty
> and is NOT the session ID of the session presently in use on that
> connection.  This can happen when the client has multiple connections
> going in parallel between the same client identity session cache and  
> the
> same remote server."
>
> Now I don't perfectly understand how Mozilla handles its "client
> identity session cache" (I suspect no one does), but it sounds  
> plausible
> to me that renegotiation with resumption could, in theory, switch
> between differing client certs over the same connection.

Yes -- and this is still the same client application ("client  
application entity"), even if it's using multiple different  
certificates.

Just for the record, I want to confirm that the Security  
Considerations language we now have in draft-ietf-tls-renegotiation-03  
resolves my concerns.

Bodo