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

mrex@sap.com (Martin Rex) Wed, 13 June 2012 05:51 UTC

Return-Path: <mrex@sap.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 7140521F874C for <tls@ietfa.amsl.com>; Tue, 12 Jun 2012 22:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 AZdHCFNqWcNj for <tls@ietfa.amsl.com>; Tue, 12 Jun 2012 22:51:19 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE7421F874A for <tls@ietf.org>; Tue, 12 Jun 2012 22:51:18 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q5D5pF8Z025365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2012 07:51:15 +0200 (MEST)
In-Reply-To: <4FD75734.5030809@free.fr>
To: Jean-Marc Desperrier <jmdesp@free.fr>
Date: Wed, 13 Jun 2012 07:51:15 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20120613055115.75A5D1A065@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: tls@ietf.org
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
Reply-To: mrex@sap.com
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, 13 Jun 2012 05:51:20 -0000

Jean-Marc Desperrier wrote:
>
> 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.

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


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

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.


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

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.



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


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.


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

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