Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 2 Dec 2008 11:01:22 -0800

As promised at the meeting, here is an update to the OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that meets a pretty simple set of requirements for multiple algorithm support and found that the base specification does not actually say anything about how a response signature algorithm should be chosen, except that SHA-1 can be implemented.

So a perfectly legal OCSP responder could report the status of a public key certificate for an RSA signature key, signed with an RSA signature key with ECC. 

And it gets worse, if you have an ocsp responder that is managing certs signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, etc. etc.) and a status request comes in for an unknown cert, there is no data for the responder to choose a reasonble response alg. You are forced to choose a lowest common denominator alg which is a problem if you moved to ECC because RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes on standards track and if we progress OCSP from PROPOSED to DRAFT we dump the explanatory part and merge the normative text in.

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02 

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been successfuly submitted by Phillip Hallam-Baker and posted to the IETF repository.

Filename:	 draft-hallambaker-ocspagility
Revision:	 02
Title:		 OCSP Algorithm Agility
Creation_date:	 2008-12-02
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.

The IETF Secretariat.

---

From: Michael Myers <[email-masked]>
Date: Tue, 2 Dec 2008 20:26:27 -0700

Phil,

I will give it a read and comment accordingly.

Mike

On Dec 2, 2008, at 12:01 PM, Hallam-Baker, Phillip wrote:

> The basic history here is that we tried to deploy an OCSP resolver  
> that meets a pretty simple set of requirements for multiple  
> algorithm support and found that the base specification does not  
> actually say anything about how a response signature algorithm  
> should be chosen, except that SHA-1 can be implemented.
>
>
> So a perfectly legal OCSP responder could report the status of a  
> public key certificate for an RSA signature key, signed with an RSA  
> signature key with ECC.
>
> And it gets worse, if you have an ocsp responder that is managing  
> certs signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA- 
> ECC, DSA, etc. etc.) and a status request comes in for an unknown  
> cert, there is no data for the responder to choose a reasonble  
> response alg. You are forced to choose a lowest common denominator  
> alg which is a problem if you moved to ECC because RSA 4096 does not  
> cut it.
>
>
> So this is a pretty simple fix to sort it out. I suggest that this  
> goes on standards track and if we progress OCSP from PROPOSED to  
> DRAFT we dump the explanatory part and merge the normative text in.
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Dec 2008 09:21:37 +0000

Phil,

I have a few comments on the draft:

This is more a nit, but I don't think the following is a compelling argument, strong enough to be mentioned:
   o  An implementation may intentionally wish to guard against the
      possibility of a compromise resulting from a signature algorithm
      compromise by employing two separate encryption algorithms.

If an implementation is securing two co-dependent messages with two different algorithms, where breaking one of them successfully compromises the system, then you have increased your risk of compromise rather than reducing it.

Further, I would like to see some explicit text, explaining that this approach is not applicable, or at least should not be used in combination with implementations of 5019.
Section 4.2. do state that the server can pre-produce several responses to the same request signed with different algorithms, but what I'm most concerned with is that clients including the extension in the request, in combination with RFC 5019 implementations may mess up http caching. Http caching is an important aspect of achieving scalability for LW OCSP.

I would prefer to entirely discourage the use of this client extension with RFC 5019, but at least discuss the issue in the draft to make implementers aware of the problem.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: [email-masked]
Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02

Abstract:

The IETF Secretariat.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 11 Dec 2008 03:50:59 -0800

On the first issue, it depends on your implementation. If two signature algorithms are used and clients accept either then the result is to weaken the protection. If two algorithms are required and either clients are required to check both or there is a mechanism to disable use of a compromised algorithm the net result is stronger.

In the case of checking a cert chain and an OCSP validation chain the second considerations apply.

On the 5019 issue, happy to extend the draft, just preferred to get something in ASAP and need to get my head around the concerns first.

-----Original Message-----
From: [email-masked] on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 
 
Phil,

 

Stefan Santesson

Senior Program Manager

 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02

Abstract:

The IETF Secretariat.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 28 Dec 2008 05:42:27 -0800

1) On the issue of algorithm strength. The problem here is that the accepted strength of an algorithm may change during the validity period of the cert. So RSA 1024 might be perfectly acceptable for use in conjunction with an OCSP validity check mechanism, provided that the OCSP check is solid.

We have for many years had the luxury of being able to avoid concerns for crypto algorithm strength by simply adding more bits. Let that continue for as long as possible, but if it does happen there are a lot of edge cases that are likely to be thrown up during the transition that are ugly.

Another case that I have been looking at a lot recently is one where a device that is incapable of doing public key crypto is being used in a PKI. This is for SCADA type applications. Believe it or not it is entirely possible to make this situation work with very low cost, low power micro-controller devices. There was a lot of work done on this early on in the development of PKI but the ideas were mostly dropped as (1) workstation class machines became ubiquitous and the CPU overhead issue became moot and (2) these approaches decrease the CPU overhead at the periphery by concentrating it at the server, not a winning strategy in 1985, but one that is entirely practical today.

These are devices that have too little RAM to generate an RSA 2048 bit signature, let alone an Ethernet packet. But they can do AES and there are serious reasons for doing so.

2) I left RFC 5019 out of consideration entirely when writing the draft. Looking over it again I think that it already makes the decisions for us, all we need to do is to make reference to the existing decision here, perhaps adding an explanation of the reason why. Cache busting is already discouraged in 5019.

Use of request extensions is already a SHOULD NOT in RFC 5019, so this would be carried over here. Applications SHOULD NOT be using the algorithm selector extension unless there is a compatibility driven reason not to. I think we should state this and give the reason (cache busting) as the whole point of a SHOULD NOT is that there is a potential balance. If an application absolutely needs to specify the extension to function then that takes priority over cache busting.

-----Original Message-----
From: [email-masked] on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 
 
Phil,

 

Stefan Santesson

Senior Program Manager

 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02

Abstract:

The IETF Secretariat.