Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt)

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Thu, 31 May 2012 13:13:13 +0200, Rob Stradling  
<[e-mail]> wrote:

> Yngve,
>
> IIRC, when Opera does an online revocation check, it currently checks  
> CRLs for intermediate CA certificates and OCSP for end-entity  
> certificates.  This makes sense because:
>    - CRLs covering intermediate CA certificates tend to be roughly the  
> same size (sometimes smaller!) as the equivalent OCSP Responses (since  
> it's quite rare for intermediate CA certificates to be revoked).
>    - Possessing a current CRL means you won't have to do an online  
> revocation check if you encounter another certificate issued by the same  
> issuer.
>
> How would you feel about updating the multi-stapling I-D so that it  
> permits CRLs to be stapled (with a note to implementers that they should  
> only staple CRLs that are deemed to be "small enough")?

Like Martin Rex, I am concerned that this would significantly increase the  
complexity of the system:

  - The servers would have to download both, and then decide which to use.

  - Clients might need to associate the CRL data with the relevant CRL URL  
in their cache (in case the client can use it later), but this might lead  
to cache poisoning (the CRL might be valid, but it has been obsoleted by a  
newer CRL revoking some cert).

  - The record format would have to be adapted, possibly including a  
datatype for each entry in the list, alternatively a completely new record  
(which would assume just one datatype was used for the intermediates)

  - Each server having a cert from the same CA would each send the CRL from  
that CA, which might require duplicate resolving if the CRL is newer than  
the one currently cached.

  - This is not suitable for the cached info extension for caching across  
multiple servers: There might be a lot of these entries, increasing  
handshake size, and it might be abused to learn which sites the user have  
visited, since the extension must be sent before we know which certificate  
the site will present.

All in all, this adds so much complexity that I don't think it would be  
worth the effort.

> Simply adding something like "case crl_multi: CRLList;" to your  
> definition of CertificateStatus.response would be problematic, because  
> it would require the server to staple a (potentially huge!) CRL for the  
> end-entity certificate too.  So...
>
> How about changing the scope of the multi-stapling I-D so that it *only*  
> covers the intermediate CA certificate(s) in the chain?
>
>
> With this approach, an end-entity OCSP Response could be stapled using  
> the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled  
> using the new multi-stapling TLS extension.

This would be even more complex, as we would either need a new handshake  
message for the new extension, or allow multiple messages, both of which  
would change the current TLS state engine.

>
> (End-entity certificate stapling is already defined in RFC6066 and this  
> existing TLS extension is already supported by many clients and servers.  
>   So why not make the multi-stapling TLS extension complement it, rather  
> than replace it?)
>
>
> On 09/05/12 16:35, [e-mail] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories. This draft is a work item of the Transport Layer Security  
>> Working Group of the IETF.
>>
>> 	Title           : The TLS Multiple Certificate Status Request Extension
>> 	Author(s)       : Yngve N. Pettersen
>> 	Filename        : draft-ietf-tls-multiple-cert-status-extension-00.txt
>> 	Pages           : 9
>> 	Date            : 2012-05-09
>>
>>     This document defines the Transport Layer Security (TLS) Certificate
>>     Status Version 2 Extension to allow clients to specify and support
>>     multiple certificate status methods.  Also defined is a new method
>>     based on the Online Certificate Status Protocol (OCSP) that servers
>>     can use to provide status information not just about the server's  
>> own
>>     certificate, but also the status of intermediate certificates in the
>>     chain.
>>
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>


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