RE: OCSP Algorithm Agility

["Santosh Chokhani" <[e-mail]>]

I meant the responder certificate delegated by the signing CA.  I can
envision responder having SHA-1 and SHA 256 certificates to facilitate
transition.  But, practically, I do not see responder having different
size RSA keys or different algorithms.  But, one could argue that
transition from RSA to EC might dictate this.  What I have found in
these transition scenarios is that having two homogenous PKI is better. 

 

I agree with your argument that if cipher suites are acceptable to
client and server, the attack more of a theoretical interest.

 

________________________________

From: Hallam-Baker, Phillip [mailto:[e-mail]] 
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: [e-mail]
[mailto:[e-mail]] 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:[e-mail]] 
	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:[e-mail]] 
		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: [e-mail]
[mailto:[e-mail]] 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.