Re: [TLS] draft-ietf-tls-cached-info-14

[Rob Stradling <[e-mail]>]

On 08/04/13 14:58, Yngve N. Pettersen wrote:
<snip>
> I am opposed to mixing in content sent by other servers,  because it
> could be a privacy violation since it would leak information about which
> CAs are used by the sites the user have visited. The information might
> change relatively often, but it could still leak information to the
> other sites.

Hi Yngve.  I need to clarify what I was proposing...

> Also, the number of entries in the list sent in the Client Hello could
> quickly become relatively large, since a client could easily encounter
> dozens of intermediate CAs in a session.

I didn't mean that the client would send CachedObjects for every 
Intermediate certificate that it has previously encountered.  Rather, I 
meant that the client would only send CachedObjects for Intermediate 
certificates that it has good reason to believe are "relevant" for this 
connection.

> The only way something like this would work without becoming a security
> problem is that the client would first know that the server is using the
> same intermediate CA as one or more other servers it have visited, which
> means that the server must send the entire response anyway, so there is
> no saving of bytes on the wire.

Agreed, but only for the client's first ever visit to a site.  My 
proposal attempts to save bytes on the wire for subsequent full 
handshakes to the same site (for as long as the same End-entity 
certificate is used).

> Optimizing storage on the client is a separate matter, best left to the
> implementers.
>
> IMO the Cached Info extension can *only* concern itself with information
> received from the current server, *never* what has been received by
> another server. It might be that this should be spelled out in the spec,
> perhaps in the security considerations, at least.

When the client sends the ClientHello for a full handshake, it has not 
yet authenticated that "the current server" is indeed the same server 
from which it previously retrieved certain information.  All the client 
has done so far is a (potentially insecure) DNS lookup.

And anyway, I was only envisaging that clients would send CachedObjects 
of OCSP Responses that have "been received by another server" in cases 
where it would be safe to do so.
Example:
   - Client visits https://www.google.com and https://mail.google.com, 
each for the first time ever, and caches the certificate chains and OCSP 
Responses for the End-entity and Intermediate certs.  Client observes 
that the same "Google Internet Authority" Intermediate is used in both 
cases.
   - A while later, client performs another full handshake to 
https://www.google.com and gets back a different OCSP Response (with a 
more recent thisUpdate value) for the same Intermediate cert.
   - A while later, client performs another full handshake to 
https://mail.google.com.  It sends the CachedObject for the Intermediate 
OCSP Response that https://www.google.com just returned, because it 
knows that this OCSP Response is relevant for the Intermediate cert that 
https://mail.google.com used last time the client connected to it, and 
because this OCSP Response is the freshest one that the client has 
available.

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online