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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Wed, 20 June 2012 11:56 UTC

Return-Path: <yngve@opera.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248B521F86EA for <tls@ietfa.amsl.com>; Wed, 20 Jun 2012 04:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2woNgFneeLz for <tls@ietfa.amsl.com>; Wed, 20 Jun 2012 04:55:59 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id E01C321F86E0 for <tls@ietf.org>; Wed, 20 Jun 2012 04:55:58 -0700 (PDT)
Received: from damia.oslo.osa (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q5KBttlT005935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2012 11:55:56 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
Organization: Opera Software
References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> <4FC75249.3050805@comodo.com> <op.wfdji1xiqrq7tp@acorna.invalid.invalid> <4FD75734.5030809@free.fr>
To: tls@ietf.org, Jean-Marc Desperrier <jmdesp@free.fr>
From: Yngve Nysaeter Pettersen <yngve@opera.com>
Date: Wed, 20 Jun 2012 13:55:53 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.wf693fsyvqd7e2@damia.oslo.osa>
In-Reply-To: <4FD75734.5030809@free.fr>
User-Agent: Opera Mail/11.64 (Win32)
Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2012 11:56:00 -0000

On Tue, 12 Jun 2012 16:50:28 +0200, Jean-Marc Desperrier <jmdesp@free.fr>
wrote:

> 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:
>>  - The servers would have to download both, and then decide which to  
>> use.
> 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.

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.

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

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

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

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.

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

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

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

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.

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

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: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************