Re: [TLS] Wrapping up cached info

["Brian Smith" <[e-mail]>]

Nicolas Williams wrote:
> On Thu, May 27, 2010 at 10:38:09AM -0500, Brian Smith wrote:
> > Martin Rex wrote:
> > > I think that should be described in the Security Considerations that
> > > a client or client&server that perform renegotiation for the purpose
> > > of client identity protection may want to tag their cached values
> > > so that when that value was established on an encrypted handshake,
> > > it is not going to be proposed by the client on a successor
> > > plaintext handshake.
> 
> Yes.
> 
> > How would the server indicate this to the client?
> 
> There's no need for the server to indicate anything to the client here.
> 
> If a client wouldn't attempt user authentication w/o re-negotiation then
> it shouldn't send a hash of its user cert / cert chain in the initial
> handshake.  If a server considers user cert TAs to be confidential
> (highly unlikely, but let's suppose) then the server shouldn't list
> their hashes in initial handshakes.  It's that simple.

AFAICT, that wouldn't stop a compliant (to the current draft) client from
sending the hashes. Even if the server previously indicated that it didn't
support the extension and/or didn't support caching certain information
items, a complaint (to the current draft) client is still allowed to send
those hashes:

     A cached_information extension provided in the server hello has the
     following semantics:

     o An empty cached_information extension indicates that the server
       supports information caching but provides no information about
       what information types it supports.

     o A non-empty cached information extension indicates that the
       server supports only those CachedInformationType types that are
       identified by each present CachedObject.

     o A CachedObject with an empty digest_value indicates that the
       server supports caching of the specified object type
       (CachedInformationType), but does not specify any digest values
       it will accept.

Regards,
Brian