Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension

["Yngve Nysaeter Pettersen" <[e-mail]>]

On Wed, 28 Jul 2010 23:03:44 +0200, Brian Smith <[e-mail]>  
wrote:

> Adam Langley wrote:
>> On Tue, Jul 27, 2010 at 6:35 AM, Yngve Nysaeter Pettersen
>> <[e-mail]> wrote:
>> > Based on the ongoing PKIX discussion about an update of OCSP, I
>> > (finally) realized the the problem my multiple-ocsp TLS extension is
>> > designed to fix can be fixed in another way, by adding an OCSP
>> > extension instead.
>>
>> I would welcome not having to change TLS to support multiple
>> OCSP responses.
>>
>> However, with TLS changes, we can deploy without any action on
>> the part of the OCSP responders. That makes it a possibility. If we
>> are beholden to updating the responders then I fear that it'll never
>> happen.
>
> Plus, it is a privacy issue. If you rely on the CAs to provide this
> extension in their OCSP responses, then any CAs that want OCSP traffic  
> (for
> user tracking) can just omit the OCSP extension. The multiple OCSP method
> lets the server improve the user's privacy without any cooperation from  
> the
> CAs involved.

This issue will not be any different from the current situation; When they  
check OCSP, clients only check the site certificate. If they check  
revocation for intermediates they use CRLs. In fact, for Opera's part, we  
retrieve CRLs while verifying the certificate, OCSP after the certificate  
has been checked, so CRLs are more "dangerous" from that perspective.

As for your MITM scenario, if the intention is to detect which computers  
access a certain site, then the attacker will already have that  
information when he performs the MITM attack.

Opera does not send or accept cookies in OCSP/CRL requests, so there would  
be no extra information available.

> (Most TLS clients issue their OCSP requests before they've
> authenticated the server's Certificate and (lack of) CertificateStatus
> messages, so while a CA wouldn't be able to force clients to make the  
> OCSP
> requests, a MiTM can still force them to do so. This could be prevented
> by moving the CertificateStatus and CertificateRequest before the
> ServerKeyExchange, and making the ServerKeyExchange signature work like  
> the
> CertificateVerify signature, hashing all the prior handshake messages.  
> This
> is something that should be considered for extensions like Snap Start  
> that
> modify the structure of the handshake, and for the next versions of TLS).
>
> Regards,
> Brian
>


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************