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

["Yngve N. Pettersen" <[e-mail]>]

On Mon, 08 Apr 2013 21:52:45 +0200, Rob Stradling  
<[e-mail]> wrote:

> 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.

I was primarily reacting to this in your post:

>>   - It's common for OCSP Responses for Intermediate certificates to be 
>> valid for much longer than OCSP Responses for End-entity certificates.
>> Also, it's common for clients to encounter multiple End-entity  
>> certificatesissued by the same Intermediate certificate.  For these  
>> reasons, it will
>> often be the case that a client has already cached the OCSP Response for
>> the Intermediate(s) and will therefore only need the server to send the 
>> OCSP Response for the End-entity certificate.


> 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.

s/safe/"safe"/

> 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.

What about www.co.uk and bank.co.uk?

Such things get complicated very fast, which is why we had to develop the  
public suffix list.

Please, let us stay way, way, *way* out of that particular thorny area.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/