Subject: RE: OCSP Algorithm Agility

From: "Andrews, Rick" <[email-masked]>
Date: Wed, 3 Oct 2007 12:29:26 -0700

Santosh,

Sorry for the long delay in responding - travel and vacation.
 
Not all OCSP responders work from CRLs, so they won't take their cue
from the CRL. Nor should they take their cue from the signature on the
cert in question, I believe. Let me try to restate my argument in a
different way.
 
With SCVP delegated path validation, the client requesting a cert's
status from an OCSP responder will be different from the client at the
other end of the SSL connection. Those two clients may have very
different capabilities in terms of supported signature and hash
algorithms. It's not realistic to expect that all SSL clients, all SCVP
servers, and all CAs will be able to upgrade in lockstep to new
algorithms as they are developed. Allowing the OCSP client and server to
negotiate a mutually-acceptable set of algorithms is essential to the
deployment of newer, stronger algorithms.
 
Likewise, companies that run large OCSP responders may wish to gradually
move to ECC-based signatures for all their OCSP responses, even those
for certs with RSA or DSA keys, because ECC signatures are cheaper to
produce. If algorithm agility is added to OCSP, those companies can
gradually achieve the move to ECC without disrupting the installed base
of OCSP clients that don't support ECC.
 
-Rick Andrews 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Friday, September 21, 2007 2:45 PM
> To: Paul Hoffman; Stephen Kent; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> Paul,
> 
> Here are my views on this.
> 
> The client should be first asking for the algorithm suite 
> that signed the certificate in question.  There is no need 
> for the client to ask for anything stronger.  The client can 
> ask for stronger suites as secondary, if client has them.
> 
> In the scenario you cite, the Responder certificate will not 
> include RSA with SHA 1 any longer.  So, client will know that 
> Responder only supported his second choice and he should be 
> ok with it.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Paul Hoffman
> Sent: Friday, September 21, 2007 4:39 PM
> To: Stephen Kent; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> >How about defining an extension to be included in the cert 
> issued to an 
> >OCSP responder by a CA.  The extension would have an ordered list of 
> >algorithms (hash and signature if we want to address more 
> than the hash 
> >agility issue) accepted by the OCSP responder.  An OCSP 
> client can use 
> >this info to determine what is the "best" algorithm (or alg 
> pair) that 
> >it and the responder share. The combination of this extension and an 
> >OCSP negotiation procedure will allow the client to detect MITM 
> >downgrade attacks. In fact, if the client acquires the 
> responder's cert 
> >prior to making a request, there would not even be a need for real 
> >negotiation, since the client would know what alg to request in a 
> >response.
> 
> Imagine the list of algorithms is RSA-with-SHA1 first and
> DSA-with-SHA1 second. How does your negotiation work? The 
> client asks for this message to be signed with RSA-with-SHA1. 
> But the server knows that RSA-with-SHA1 has been compromised 
> since it got that certificate from the CA. What does the 
> server say to the client to indicate that it only wants to 
> sign with DSA-with-SHA1? What prevents Mallory from saying 
> the same thing to the client?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 6 Oct 2007 13:12:19 -0700

Rick,

SCVP or other intermediaries are red herring.  Whoever processes the
certificate processes the revocation information for that certificate.
It does not change the following:

1.  There is no security benefit in using a stronger algorithm for OCSP
response than for the certificate in question.   Neither, there is any
benefit from interoperability viewpoint for these two to be different.

2.  If the OCSP Responder does not get a CRL, it can use the same
mechanism to get the hashing algorithm used as it uses to get the
revocation information. 

-----Original Message-----
From: Andrews, Rick [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 3:29 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

Santosh,

 

-Rick Andrews

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 Oct 2007 16:26:57 -0700

The objective here is to overcome a real deployment obstacle that creates a lockstep issue when use of stronger algorithms is attempted.

The CA cannot issue a certificate that employs a new algorithm until it is known that all clients that might rely on the certificate are capable of processing the new certificate. Requiring lockstep updates to the OCSP and SCVP infrastructure to be made at the same time renders transition to stronger algorithms a much lengthier and much less practical proposition.

> Sent: Saturday, October 06, 2007 4:12 PM
> To: Andrews, Rick; [email-masked]
> SCVP or other intermediaries are red herring.  Whoever 
> processes the certificate processes the revocation 
> information for that certificate.
> 2.  If the OCSP Responder does not get a CRL, it can use the 
> same mechanism to get the hashing algorithm used as it uses 
> to get the revocation information. 
> 
> Not all OCSP responders work from CRLs, so they won't take 
> their cue from the CRL. Nor should they take their cue from 
> the signature on the cert in question, I believe. Let me try 
> to restate my argument in a different way.
>  
> With SCVP delegated path validation, the client requesting a 
> cert's status from an OCSP responder will be different from 
> the client at the other end of the SSL connection. Those two 
> clients may have very different capabilities in terms of 
> supported signature and hash algorithms. It's not realistic 
> to expect that all SSL clients, all SCVP servers, and all CAs 
> will be able to upgrade in lockstep to new algorithms as they 
> are developed. Allowing the OCSP client and server to 
> negotiate a mutually-acceptable set of algorithms is 
> essential to the deployment of newer, stronger algorithms.
>  
> Likewise, companies that run large OCSP responders may wish 
> to gradually move to ECC-based signatures for all their OCSP 
> responses, even those for certs with RSA or DSA keys, because 
> ECC signatures are cheaper to produce. If algorithm agility 
> is added to OCSP, those companies can gradually achieve the 
> move to ECC without disrupting the installed base of OCSP 
> clients that don't support ECC.
>  
> -Rick Andrews 
> 
> that signed 
> > the certificate in question.  There is no need for the 
> client to ask 
> > for anything stronger.  The client can ask for stronger suites as 
> > secondary, if client has them.
> > 
> > In the scenario you cite, the Responder certificate will 
> not include 
> > RSA with SHA 1 any longer.  So, client will know that 
> Responder only 
> > supported his second choice and he should be ok with it.
> > 
> client asks 
> > for this message to be signed with RSA-with-SHA1.
> > But the server knows that RSA-with-SHA1 has been 
> compromised since it 
> > got that certificate from the CA. What does the server say to the 
> > client to indicate that it only wants to sign with 
> DSA-with-SHA1? What 
> > prevents Mallory from saying the same thing to the client?
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium
> > 
> > 
> > 
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Oct 2007 08:15:40 -0700

The OCSP and SCVP can transition to stronger algorithms any time they
want.

The OCSP can take their clue from the CA or the certID field to decide
the hashing algorithm.  When multiple certID is present, OCSP can take
low water mark of these.

SCVP is no different than a client in terms of validating a path.  In
terms of signing a response, it can take the low water mark of the
hashing algorithms in the certificate chain.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 08, 2007 7:27 PM
To: Santosh Chokhani; Andrews, Rick; [email-masked]
Subject: RE: OCSP Algorithm Agility

The objective here is to overcome a real deployment obstacle that
creates a lockstep issue when use of stronger algorithms is attempted.

The CA cannot issue a certificate that employs a new algorithm until it
is known that all clients that might rely on the certificate are capable
of processing the new certificate. Requiring lockstep updates to the
OCSP and SCVP infrastructure to be made at the same time renders
transition to stronger algorithms a much lengthier and much less
practical proposition.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 9 Oct 2007 11:06:36 -0700

Not if they don't know that the client can understand them they can't.

And the issue is not just hashing algorithms, it is signature algorithms. Like your previous posts you continue to assume that cipher strength is a linear quantity with only one dimension and that any client which supports strength 2X must automatically support strength X. 

That is not the case if you consider the practicalities of deploying ECC in an RSA world. 

To give a practical example, VeriSign issues a cert for an ECC key signed with an ECC key. The email program on Alice's machine in the DHS supports ECC but not the DHS SCVP server or OCSP relay.

In the real world the OCSP service does not have a necessary connection to the CA. There are plenty of commercial OCSP offerings that report on certificates issued by other CAs. 

> Sent: Tuesday, October 09, 2007 11:16 AM
> To: Hallam-Baker, Phillip; [email-masked]
> The OCSP and SCVP can transition to stronger algorithms any 
> time they want.
> 
> The OCSP can take their clue from the CA or the certID field 
> to decide the hashing algorithm.  When multiple certID is 
> present, OCSP can take low water mark of these.
> 
> SCVP is no different than a client in terms of validating a 
> path.  In terms of signing a response, it can take the low 
> water mark of the hashing algorithms in the certificate chain.
> 
> The objective here is to overcome a real deployment obstacle 
> that creates a lockstep issue when use of stronger algorithms 
> is attempted.
> 
> The CA cannot issue a certificate that employs a new 
> algorithm until it is known that all clients that might rely 
> on the certificate are capable of processing the new 
> certificate. Requiring lockstep updates to the OCSP and SCVP 
> infrastructure to be made at the same time renders transition 
> to stronger algorithms a much lengthier and much less 
> practical proposition.
> 
> 
> processes the 
> their cue 
> > algorithms. It's not realistic to expect that all SSL clients, all 
> > SCVP servers, and all CAs will be able to upgrade in 
> lockstep to new 
> > algorithms as they are developed. Allowing the OCSP client 
> and server 
> > to negotiate a mutually-acceptable set of algorithms is 
> essential to 
> > the deployment of newer, stronger algorithms.
> >  
> > Likewise, companies that run large OCSP responders may wish to 
> > gradually move to ECC-based signatures for all their OCSP 
> responses, 
> > even those for certs with RSA or DSA keys, because ECC 
> signatures are 
> > cheaper to produce. If algorithm agility is added to OCSP, those 
> > companies can gradually achieve the move to ECC without 
> disrupting the 
> > installed base of OCSP clients that don't support ECC.
> >  
> > -Rick Andrews
> >

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 10 Oct 2007 11:28:06 -0700

See responses in-line below.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

Not if they don't know that the client can understand them they can't.
[Santosh Chokhani] The Responder has two ways to know what the client
understands.  From certID or from CA.  If the client does not understand
the algorithm used in certificate signing, revocation information is
useless.

And the issue is not just hashing algorithms, it is signature
algorithms. 
Like your previous posts you continue to assume that cipher strength is
a linear quantity with only one dimension and that any client which
supports strength 2X must automatically support strength X. 
[Santosh Chokhani] I am making no such assumptions.  I am saying that if
an algorithm is good enough for a certificate, it is good enough for
revocation notification for that certificate.

That is not the case if you consider the practicalities of deploying ECC
in an RSA world. 

To give a practical example, VeriSign issues a cert for an ECC key
signed with an ECC key. The email program on Alice's machine in the DHS
supports ECC but not the DHS SCVP server or OCSP relay.
[Santosh Chokhani] And what is the problem with that?  They have no
choice but to use RSA.

In the real world the OCSP service does not have a necessary connection
to the CA. There are plenty of commercial OCSP offerings that report on
certificates issued by other CAs. 
[Santosh Chokhani] And how does this relate to algorithm agility?  If
the OCSP does not do ECDSA it won't.  If OCSP supports both RSA and
ECDSA, it can take the cue from the CA CRL to determine what algorithm
to use for signing OCSP responses.  If the OCSP does not consume CRL,
the mechanism that tells it revocation information can also tell it the
signature algorithm to use.

---

From: "Seth Hitchings" <[email-masked]>
Date: Wed, 10 Oct 2007 15:25:47 -0400

I'm generally in favor of simpler approaches, such as those suggested by
Santosh, as they favor interoperability. Updating deployed applications to
understand new elements of the protocol could take just as long to roll out
as the new algorithm support that's purportedly lacking.

I can see a situation in which the CA cannot assume that the entire user
population understands a new algorithm such as SHA-256, and thus has to
continue using SHA-1 with RSA when signing certificates. Individual clients
that do understand SHA-256 may wish to receive OCSP responses signed using
SHA-256 with RSA, and would need a way to signal their desires to the OCSP
responder.

The question is, then, is there any security benefit to having the signature
algorithm on the OCSP response stronger than the signature algorithm on the
certificate? If you can break the algorithm and cause me to accept a
contrived OCSP response, could you not do the same thing with a certificate?

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Wednesday, October 10, 2007 2:28 PM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: OCSP Algorithm Agility

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2007 12:14:55 +0100

I'm generally supportive of the following statement.

> as the new algorithm support that's purportedly lacking.

I've been trying to take a step back to think what I would need from a more practical viewpoint.

Security:
None of the presented threats is not a great concern for me. Downgrade attacks is only useful if we use algorithms that can be broken.
I would expect an organization to only allow algorithms that provide adequate security.
The stolen OCSP key is neither a problem for me from a protocol perspective. We have revocation.

Practical matters:
I can only find one practical matter that concerns me. I have an OCSP server and of some reason I want to gradually transition responses to be based on say ECC with SHA 256. Some clients can only verify RSA with SHA-1. The reason for doing this transition may be entirely policy oriented. Now I would like to know which clients that can actually verify my upgraded responses.

I see some value in the client knowing which algorithms the server can support, but not greatly. The client can mostly learn the capability of a server by observing its responses.

What can I do today:
The server can draw a number of conclusions today.

1) Looking at the hashAlgorithm of the CertID
2) Looking at the signatureAlgorithm used by the client to sign the response
3) Looking at the certificate actually being validated

None of these are 100% bulletproof to cover all corner cases. But are they good enough and is the remaining gap big enough to motivate a protocol update?

Possible updates:
To cover the corner cases I have seen the following options:
Client declaration - through a singleRequestExtension
Server declaration - through responseExtensions, or through an extension in the responder certificate.

Conclusion:
I'm not convinced I need any update of OCSP. If we do an update anyway, I'm more interested in the client declaration than the server declaration problem.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Seth Hitchings
> Sent: den 10 oktober 2007 21:26
> To: Santosh Chokhani; Hallam-Baker, Phillip; [email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 15 Oct 2007 09:58:45 -0700

From: [email-masked] on behalf of Stefan Santesson

>Security:
>None of the presented threats is not a great concern for me. 
>Downgrade attacks is only useful if we use algorithms that can be broken.

Agreed, the issue here is not security, it is interoperability. 

>Practical matters:
>I can only find one practical matter that concerns me. I have an OCSP server and of 
>some reason I want to gradually transition responses to be based on say ECC with 
>SHA 256. Some clients can only verify RSA with SHA-1. The reason for doing this 
>transition may be entirely policy oriented. Now I would like to know which clients 
>that can actually verify my upgraded responses.

That is the concern that led to the proposal. 
 
The assumption that the OCSP client supports the same set of algorithms as the 
certificate relying application does not hold 

>None of these are 100% bulletproof to cover all corner cases. But are they 
>good enough and is the remaining gap big enough to motivate a protocol update?
 
As a design principle I prefer a protocol where the client can specify
what it wants over one where the only option is for the server to guess.
 
I find that approach is much more likely to lead to reliable interoperation.

The solution proposed is 100% backwards compatible, the old approach being:
1 Server guesses what algorithms the client supports
 
The new approach is:
1 Server looks to see if the client specified what algorithms are supported by the client
2 If none specified server guesses what algorithms the client supports as before

If either the client or the server does not support the proposed extension 
the other party simply downgrades to the status quo.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 15 Oct 2007 20:35:50 -0700

Whether a server could make a sensible choice is beside the point.
 
For a specification to provide an interoperable standard we must have a definitive statement. Otherwise interoperability ends up depending on heuristics and undocumented assumptions.
 
Unless I missed the section in the RFC that describes the algorithm agility strategy it seems to me we must either:
 
1) Document the server algorithm selection as proposed by Santosh
2) Doucment the server algorithm selection as proposed by Santosh with an optional extension to allow the client to specify the choices it supports.
 
Either way we need a draft if we are going to meet the algorithm agility requirement.

________________________________

From: [email-masked] on behalf of Seth Hitchings
Sent: Wed 10/10/2007 3:25 PM
To: Santosh Chokhani; Hallam-Baker, Phillip; [email-masked]
Subject: RE: OCSP Algorithm Agility

Seth

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 16 Oct 2007 12:11:03 -0700

I agree that the RFC 2560 should be revised for a variety of reasons.

It would be nice to have a set of client side request composition and
response processing rules (a la Section 6 of RFC 3290).

We probably can not mandate that in delegated model certificate in
question and OCSP Responder should be signed by the same CA key, but we
can recommend it and add some language in the Security Considerations
section the residual risk of not doing that.

For hashing algorithm, certID should be sufficient and should be the
same the as the hashing algorithm, used for the certificate.  We of
course will need to spell this out in the revision.

For signature, we can add an extension, but this should state the
algorithm used for the certificate.  We of course will need to spell
this out also in the revision.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 15, 2007 11:36 PM
To: Seth Hitchings; Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

For a specification to provide an interoperable standard we must have a
definitive statement. Otherwise interoperability ends up depending on
heuristics and undocumented assumptions.

Unless I missed the section in the RFC that describes the algorithm
agility strategy it seems to me we must either:

2) Doucment the server algorithm selection as proposed by Santosh with
an optional extension to allow the client to specify the choices it
supports.

Either way we need a draft if we are going to meet the algorithm agility
requirement.

I'm generally in favor of simpler approaches, such as those suggested by
Santosh, as they favor interoperability. Updating deployed applications
to
understand new elements of the protocol could take just as long to roll
out
as the new algorithm support that's purportedly lacking.

I can see a situation in which the CA cannot assume that the entire user
population understands a new algorithm such as SHA-256, and thus has to
continue using SHA-1 with RSA when signing certificates. Individual
clients
that do understand SHA-256 may wish to receive OCSP responses signed
using
SHA-256 with RSA, and would need a way to signal their desires to the
OCSP
responder.

The question is, then, is there any security benefit to having the
signature
algorithm on the OCSP response stronger than the signature algorithm on
the
certificate? If you can break the algorithm and cause me to accept a
contrived OCSP response, could you not do the same thing with a
certificate?

Seth

-----Original Message-----
On