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

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 17:08:54 +0200 (CEST)

Rob Stradling wrote:
> 
> 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 about changing the scope of the multi-stapling I-D so that it *only* 
> covers the intermediate CA certificate(s) in the chain?

This would significantly increase the complexity without adding value.
OCSP responses can be cached just as long as the CRLs on which they're
based.

> 
> 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 require the complexity of two TLS extensions where a single
TLS extension is perfectly sufficient (i.e. a lot more code and a lot
more bugs).

While I might eventually look into implementing the multi-stapling
TLS extension, I will never consider doing the rfc6066 single OCSP
extension.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Jun 2012 08:13:57 -0700

> TLS extension, I will never consider doing the rfc6066 single OCSP

FWIW, Chrome already supports RFC 6066 and it's in process
for Firefox.

-Ekr

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 04 Jun 2012 12:31:39 +0200

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

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

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, [email-masked] 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 12 Jun 2012 10:50:28 -0400

On 04/06/2012 06:31, Yngve N. Pettersen (Developer Opera Software ASA) 
wrote:
> Like Martin Rex, I am concerned that this would significantly increase 
> the complexity of the system:
Not necessarily, the extension is still very useful if the servers 
systematically downloads the OCSP where available, and CRL when the 
intermediate CA have no OCSP. Or has been initially configured to do 
only one of the two.

The biggest problem with the OCSP only mode is that in many cases 
intermediate CA do not have OCSP responders, so that in practice, either 
the client doesn't check intermediate levels, or it will still have to 
do several network requests when using multi.

>  - 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).
>
Sounds valid until you realize that the CRL protocol currently does 
*nothing* to try to protect against outdated CRL poisoning.
It is not an aim, and if it were to become one, there would be a lot of 
other things to change.

They are many different strategy an attacker can currently use to poison 
the CRL cache with outdated entries, or to send a large scale attack 
target that will work against all victims that have their cache loaded 
with an old version of the CRL.

> datatype for each entry in the list, alternatively a completely new 
> record (which would assume just one datatype was used for the 
> intermediates)
It makes sense to try to keep this as simple as possible and not handle 
too many different cases.

This could be done by adding just one additional status_type for the 
response, that includes the same  OCSPResponseList format as ocsp_multi, 
but where all level except the end entity one are defined to contain CRL 
entries.
And maybe making it a MUST for client to also accept this format when 
they request a multi-cert status.

>  - 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.
I'm sorry I don't get what you mean exactly here. Duplicate resolving of 
what ? Duplicate downloading maybe.

>  - 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.
Right now the cached info extension draft defines caching of only 
certificates path and trusted CA, not revocation info. Sending a lot of 
cached info entries quite defeats the purpose of the extension IMO. They 
are a few sites that use multiple certificates under separate 
hierarchies for the same dns name, but I don't really get how multi with 
CRL makes the situation actually worse as compared to the current case 
with OCSP only.

And also the best path would be not to implement support for this case 
in the constrained clients that are the target of thecached information 
extension and evangelize the concerned sites to just not do that. If the 
site really has many different certificates, won't this overflow the 
cache capacity of the constrained client anyway ?

> All in all, this adds so much complexity that I don't think it would 
> be worth the effort.
It would be nice to have also the opinion of other implementers.
And of the CAs for which emitting new intermediate certs with OCSP 
information, and managing the added OCSP responder is a significant 
burden. It would not be nice if the end result is that cert multi is of 
no use with them since they don't provide the intermediate OCSP anyway. 
Let's be honest, it's the small CAs that are the most significant 
security risk.

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Jun 2012 07:51:15 +0200 (CEST)

Jean-Marc Desperrier wrote:
>
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> >

Nope.  When intermediate CAs have no OCSP, no OCSP check will be performed.

Personally, I would never do CRL processing on a client during Online
authentication, because CRL processing is so completely screwed in
the standards (CRLs offers tons of complex features that have a guidance
-- if you don't understand this, get another CRL ...).

In terms of processing it, OCSP responses are a magnitude more reasonable
than CRLs (except that expecting the cert receiver instead of the cert
owner to shop around, that's a problem inherited from CRLs).

> with an old version of the CRL.

The use of the CRL to verify the server cert is to protect against the
*network peer* being the attacker.  Since the network peer in the case
of OCSP stapling is the source of these CRLs, this argument does not apply.

> what ? Duplicate downloading maybe.

I'm also slightly confused.  For the sake of robust and deterministically
predictable behaviour, either the conveyed stapled data ought to be used,
or the handshake aborted with an error.  Overriding data sent by the
server with stuff already in the cache or ignoring a fraction of them
and newly obtaining them sounds like a recipe for breaking this feature
badly, resulting in a user experience "works for some peers, but not
for others", similar to the transvalid server certificate nonsense
resulting from browser re-sorting and adding missing certs to the
certification path of the servers Certificate handshake message
instead of reporting a broken Server-side SSL/TLS implementation
that is clueless about reasonably managing PKI credentials and
correctly implementing TLS, and a server configuration that does
not accommodate for such brokenness of the SSL/TLS implementation of
the server.

> CRL makes the situation actually worse as compared to the current case 

I believe it is not as bad as you describe it.  When two communication
peers perform lots of TLS handshakes with each other in short time,
they should be using the abbreviated TLS handshake aka "TLS session resume",
in which case the server should not send any stapled OCSP responses in
the ServerHello at all.

If there is a problem with SSL session caching&resume, then that
problem should be taken care of and fixed.

> cache capacity of the constrained client anyway ?

Huh?

For a constrained client, not having to implement OCSP/CRL chasing
(= wget/curl) would be a great savings, if revocation does matter at all.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 13 Jun 2012 14:16:43 -0700

Jean-Marc Desperrier <[email-masked]> writes:

> > Like Martin Rex, I am concerned that this would significantly
> > increase the complexity of the system:
> intermediate CA do not have OCSP responders, so that in practice,
> either the client doesn't check intermediate levels, or it will still
> have to do several network requests when using multi.

Although most intermediate CAs don't have OCSP responders, the
intermediate certificates most commonly used on the Internet do.

That is to say, when I look at intermediate certificates visible on
the Internet, unexpired and signed by the CAs recognised by OS X, I
see only about 25% have OCSP responders named (321 out of 1256).  But,
when counting them by the number of IP addresses which send the
certificate, the numbers reverse and 74% of the certificates sent
(2071453 out of 2813712) have OCSP responders named.

These numbers should only improve in the future, as the CABforum
baseline requirements require new intermediate CAs to have OCSP
responders.

So, I wouldn't put a lot of effort into making CRLs more efficient in
situations where OCSP can be used instead.

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Wed, 20 Jun 2012 13:55:53 +0200

> do several network requests when using multi.

Many intermediate CAs already indicate OCSP. In fact, for a number of CAs
I polled, 30% of their OCSP traffic is for their intermediates from
clients that use that instead of CRLs to verify the intermediates.

Additionally, indicating OCSP is required by the CABForum Baseline
Requirements for CAs in all non-root certificates.

When OCSP is not available for one or more intermediates then server can
send an empty entry for that certificate, and leave it to the client to  
obtain
revocation information through other means.

> with an old version of the CRL.

My main issue is that it makes it easier to poison the cached CRL for a
given CA

> they request a multi-cert status.

The main issue is that the would likely need a *mix* of OCSP and CRL
responses. Non-EV EE CRLs are likely to be big (EV CRLs have a specific
download time requirement, limiting their size).

Therefore a flexible format is needed, which can decide OCSP or CRL for
each item in the list.

That would lead to much more complexity, and I don't think the flexibility
is worth it.

> what ? Duplicate downloading maybe.

If you get two different CRL responses from two servers, for the same CDP
URL, which one should you cache?

> CRL makes the situation actually worse as compared to the current case  

Revocation information is a likely candidate for cached info, even though
I am uncertain that it will reduce overhead by much. The revocation
information is only needed when a full handshake is performed, and on a
well configured server the session should be valid for many hours, by
which time the server could/ought to have refreshed its response copies.

In this case, I am pointing out that the only way to save general
bandwidth for CRL using cached info is to indicate the knowledge in all
connection attempts, which will be a bandwidth hog, and a privacy issue,
and therefore not suitable. It might be used for a single server, but that
means we get lots of duplicates if we are to cache the responses for use
with non-extension handshakes.

> cache capacity of the constrained client anyway ?

I was not talking about one site having many certificates, I was talking
about cross-site caching of the CRL info (extreme scenario).

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************