[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] matching identity, by default
From:       Bodo Moeller <bmoeller () acm ! org>
Date:       2010-01-12 16:55:41
Message-ID: CB10A859-5E2B-4B78-ABFB-1E045A6EFAFF () acm ! org
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]