Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

[Nicolas Williams <[e-mail]>]

On Tue, May 11, 2010 at 02:51:24PM -0500, Marsh Ray wrote:
> On 5/11/2010 2:23 PM, Nicolas Williams wrote:
> > 
> > Some of those devilish details:
> > 
> >  - Clients MUST NOT cache objects from failed handshakes.
> 
> Bad guy may see the impending failure and delay the client's recognition
> of it arbitrarily.

I didn't mean that clients could cache objects from in-progress
handshakes.  I realize that I wasn't sufficiently precise.  But thanks
for making that clear.

> >  - Clients MAY cache objects from succesful handshakes, and only when
> >    the clients authenticate the server (including validation of the
> >    server's cert chain to a TA).
> 
> It appears that in a large class of client applications, the client TLS
> stack may not even know how to fully verify the certificate until he
> returns to the application code. Commonly the TLS stack validates that
> the server's cert chains to a TA, but the application code queries for
> and checks the CN after-the-fact. The method for checking CN is
> protocol-specific.

In those cases the application should manage the cache (mostly by
calling TLS APIs that do the dirty work).  The caches for different apps
using different TAs should NOT meet.

> Does the current proposal give more semantic meaning to the exchange of
> Finished messages than was expected by such an application?

Yes, though it doesn't change the computation of the Finished message
(maybe it should!).

> >  - In particular there MUST NOT be any caching in cases where the server
> >    is authenticated by the use of pre-shared certificates.
> 
> Sorry if I missed this earlier, what's special about PSK here?

You're right, I think it isn't.  I think I must have intended to say
that apps using different TA sets (and/or pre-shared certs) must use
different caches as well.

Nico
--