Re: [TLS] matching identity, by default

Bodo Moeller <> Tue, 12 January 2010 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1F2428C0FB for <>; Tue, 12 Jan 2010 08:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.249
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yokjha95mzHR for <>; Tue, 12 Jan 2010 08:55:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E3BE23A6A20 for <>; Tue, 12 Jan 2010 08:55:54 -0800 (PST)
Received: from ([]) by (node=mreu2) with ESMTP (Nemesis) id 0MOmRO-1NYcBM0skQ-0063DN; Tue, 12 Jan 2010 17:55:43 +0100
From: Bodo Moeller <>
To: Marsh Ray <>
In-Reply-To: <>
References: <> <> <> <> <>
Message-Id: <>
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 <>, " Working Group" <>, James Manger <>
Subject: Re: [TLS] matching identity, by default
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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  

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.