RE: OCSP Algorithm Agility
"Santosh Chokhani" <chokhani@orionsec.com> Fri, 21 September 2007 01:42 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYXWt-0000Nb-5i for pkix-archive@lists.ietf.org; Thu, 20 Sep 2007 21:42:03 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYXWi-0008CY-8D for pkix-archive@lists.ietf.org; Thu, 20 Sep 2007 21:41:54 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8L0eHb4095236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2007 17:40:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8L0eHZt095235; Thu, 20 Sep 2007 17:40:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8L0eGZ7095229 for <ietf-pkix@imc.org>; Thu, 20 Sep 2007 17:40:17 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FBE8.26459FE5"
Subject: RE: OCSP Algorithm Agility
Date: Thu, 20 Sep 2007 17:39:57 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C879093E30D7@EXVS01.ex.dslextreme.net>
In-Reply-To: <0D028BDBFBA58441BD8E974691480642269DDB@MOU1WNEXMB14.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: OCSP Algorithm Agility
Thread-Index: Acf0YQuLnpqNTtmVSEemXtokNuJtUwAAJKlAADhP/rQBN68QwAAqoFWwAARfiVAAAg0EsAAHpunAACp6bUAACGOqMAAF0sKw
References: <82D5657AE1F54347A734BDD33637C879093E2CDF@EXVS01.ex.dslextreme.net> <0D028BDBFBA58441BD8E974691480642269DDB@MOU1WNEXMB14.vcorp.ad.vrsn.com>
From: Santosh Chokhani <chokhani@orionsec.com>
To: "Andrews, Rick" <RAndrews@verisign.com>, pkix <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5245c4b5b968d420d3e42566b38db1e8
Rick, Let us say that CA X starts issuing SHa-256 certificates. Clients that rely on that CA, will need to upgrade to SHA-256. The CA can start signing the CRLs using SHA-256. The OCSP Responder R can take its cue from the CRL and sign those responses with SHA-256. Now, if the same OCSP Responder R also serves CA Y who is still using SHA-1. Again, taking the cue from CRL, the same Responder R can sign the responses using SHA-1. Next, you might argue that VeriSign has a large set of disjoint customers using the same CA. I, do not think it is a big deal to have two physically or logically distinct CAs one for SHA-256 population and one for SHA-1 population. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Andrews, Rick Sent: Thursday, September 20, 2007 5:49 PM To: Santosh Chokhani; Hallam-Baker, Phillip; pkix Subject: RE: OCSP Algorithm Agility Santosh, I think it's an installed-base problem. If we start issuing certs with SHA-256, it will take a long time for all OCSP clients to build in the support. Until SHA-2 is ubiqitous, we need the server to be agile with respect to algorithms. -Rick Andrews ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Thursday, September 20, 2007 10:54 AM To: Hallam-Baker, Phillip; pkix Subject: RE: OCSP Algorithm Agility I am still have misgiving about the need for in-band signaling for SHA-1 Vs SHA-256. For practical PKI, if the certificates are still SHA-1, why does the OCSP needs to go to SHA-256? If the certificates have started using SHA-256, client better process SHA-256. I can envision the RFC to accommodate algorithms. I am not sure in-band signaling is that important. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, September 19, 2007 5:38 PM To: Santosh Chokhani; pkix Subject: RE: OCSP Algorithm Agility The problem with KISS is that the definition of simple can depend markedly on one's point of view. Simplifying assumptions can lead to great operational complexities, assuming the world to be simpler than it is tends to lead to complexity in my experience. I don't follow the assumption that the OCSP responder is using the 'certificate signing key'. which certificate, the end entity cert under test or the OCSP server cert? The OCSP server might well have multiple certs. The request is asking for a response + cert chain that meets specific criteria. The OCSP responder may not have any relation to the certificate signer whatsoever. If it is a CRL driven responder it might easily be using Suite B rather than RSA or vice versa. Putting a statement of the algorithms offered into the OCSP responder cert would certainly be one approach to closing the attack. I am not convinced that the attack is relevant but it is certainly more relevant than a great number of features we have already included in the PKIX stack. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Wednesday, September 19, 2007 1:58 PM To: Hallam-Baker, Phillip; pkix Subject: RE: OCSP Algorithm Agility Personally I believe in KISS principle, i.e., the Responder uses the key pair (hopefully it does not generate many different keys pairs for different algorithms and key sizes) and hash used to sign it certificate. Again that is the practical side of how PKIs are deployed. If you really wanted to protect against the attack and want in-band algorithm negotiation, the Responder certificate could also contain structure like you propose in a supportedAlgorithms extension. The client could make a determination if the Responder made the proper selection and detect the MITM attack. This still has residual risk of certificate minting due to weak algorithms, but that is a such as bigger problem that crypto suite selection dwarfs in comparison. ________________________________ From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] Sent: Wednesday, September 19, 2007 1:05 PM To: Santosh Chokhani; pkix Subject: RE: OCSP Algorithm Agility True, but the attacker can only force the selection of a particular algorithm that is acceptable to both the requestor and responder as acceptably secure. A negotiation has to start somewhere and there is always a situation where a downgrade attack is going to be possible. What we could do is to allow the responder to echo the algorithm request in the response so that the responder can detect a downgrade attack. But that does not get us very much further. If a requestor offers a weak algorithm they are vulnerable to a downgrade attack. We need a policy layer. One approach would be to infer the OCSP responder policy from the certificate. If the cert has an SHA-256 certificate the requestor might be able to presume that SHA-256 is supported by the OCSP responder. This is not necessarily the case though since the OCSP service might be entirely separate. A better approach would be to use security policy statements distributed through the DNS, WS-Policy or whatever. Downgrade attack is much less of a concern to me than the ability to effect a transition from SHA-1 to SHA-256 before the known vulnerabilities of SHA-1 allow an attacker to cause a compromise. If we switch to SHA-256 before the downgrade attack gives the attacker an advantage the problem is very small. The only circumstance where it is relevant is if the OCSP token is to be stored and used in a persistent document archive, and then only if it is not verified when it was obtained. ________________________________ From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, September 19, 2007 10:50 AM To: Hallam-Baker, Phillip; pkix Subject: RE: OCSP Algorithm Agility The approach provides an attacker (MITM) an opportunity to force the OCSP Responder to select weaker algorithms. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Tuesday, September 18, 2007 2:53 PM To: pkix Subject: OCSP Algorithm Agility Looking at places where we currently use SHA-1 it appears that there will soon be a need to support SHA-256 in OCSP. In particular we need a mechanism to allow the requestor to state which algorithms they can accept from the responder. I did a sketch of a scheme (see below). The question is how best to get this processed. Algorithm agility is one of the issues that is blocking advance of OCSP on the standards track so if this was the only issue that was blocking advancement it would perhaps make sense to rev the OCSP RFC. Alternatively it might be considered preferable to address algorithms agility 'across the board'. Although the only other protocol that is analagous is SCVP. I don't think the mechanism specified there translates to OCSP. So I was thinking that a good place to start was probably to submit some variation of the following as a personal ID: The extension would need to be something like id-pkix-ocsp-algorithmselectors OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } AlgorithmSelectors ::= SEQUENCE OF AlgorithmSelectorEntry AlgorithmSelectorEntry ::= SEQUENCE { SignatureAlgorithm [0] OBJECT IDENTIFIER OPTIONAL, DigestAlgorithm [1] OBJECT IDENTIFIER OPTIONAL, } The responder SHOULD sign the reponse with a signature algorithm and digest algorithm pair that match one ot the following criteria: 1) The Signature and Digest algorithm both match an algorithm selector entry exactly. or 2) The Signature Algorithm used matches an algorithm selector entry where only the Signature Algorithm OID is specified and the digest algorithm matches an algorithm selector entry where only the Digest Algorithm OID is specified. So for example a requestor can stipulate that they will accept any combination of RSA-1024, RSA-2048, SHA-1 and SHA-256 or DSA2 with SHA-256 as follows: {SignatureAlgorithm RSA-1024} {SignatureAlgorithm RSA-2048} {DigestAlgorithm SHA-1 } {DigestAlgorithm SHA-256 } {SignatureAlgorithm DSA2, DigestAlgorithm SHA-1 } The rationale here is that in most cases the signature and digest algorithms are 'mix and match'. But sometimes they are not, in particular if specific signature hardware is to be used. I note that SCVP does something rather different but I don't see how the scheme specified there would fit OCSP.
- OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Stefan Santesson
- RE: OCSP Algorithm Agility Michael Myers
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Michael Myers
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Andrews, Rick
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Andrews, Rick
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Paul Hoffman
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Stefan Santesson
- RE: OCSP Algorithm Agility Stephen Kent
- RE: OCSP Algorithm Agility Stefan Santesson
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Paul Hoffman
- RE: OCSP Algorithm Agility Stephen Kent
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Paul Hoffman
- RE: OCSP Algorithm Agility Andrews, Rick
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Santosh Chokhani
- RE: OCSP Algorithm Agility Seth Hitchings
- RE: OCSP Algorithm Agility Stefan Santesson
- RE: OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Hallam-Baker, Phillip
- RE: OCSP Algorithm Agility Santosh Chokhani