Re: [saag] SHA-1 to SHA-n transition

["Hallam-Baker, Phillip" <[e-mail]>]

Let us see, I suggest that we might need to slay a sacred PKIX cow or two in order to make the SHA-n transition work. Stephen: 
 
* Describes the suggestion as 'offensive'
* Raises a non sequitor about certificate issue policy
 
I canot imagine why Stephen would imagine that a sensible response to a technical issue would be found in relaxing certificate issue policy criteria, or for that matter why I would be likely to be suggesting that. 
 
I did however anticipate that Stephen would find my proposal objectionable. But was somewhat surprised that he didn't wait to find out what it was before objecting.
 
 
We have a problem here that requires us to work out a coherent transition plan for enabling browsers to make use of the stronger security of SHA2 and SHAn at the earliest possible date taking into account that we have a very small installed base of SHA2 capable clients and no spec for SHAn.
 
The problem is that you do not gain security from introducing stronger algorithms, you only gain security from withdrawing insecure algorithms from use. And for better or worse, there are real limits to what the Internet user base will tollerate for security.
 
So simply adding SHA2 support to existing browsers does not help us much unless we have a way to retrospectively shut off SHA1 support when it is no longer trustworthy. 
 
And even that does not help very much as there will be a large number of certificate customers who want to sell to people who can only use SHA1 capable browsers.
 
And then we have the problem that PKIX does not really have a strategy for algorithm transition. It has the ability to use multiple algorithms but not very much thought of how the transition from one to another takes place.
 

________________________________

From: [e-mail] on behalf of Stephen Kent
Sent: Sat 2/21/2009 11:10 AM
To: [e-mail]
Subject: [saag] SHA-1 to SHA-n transition


I agree wit Phil's suggestion that we begin work on this topic sooner rather than later.  Solutions probably will require coordination between folks in both PKIX and TLS, plus some browser experts from the APP area.

However, Phil's comment (underling added by me)

If we start addressing the problem now we can lay ourselves an insurance policy. If we try to insist on the pristine principles of the PKIX infrastructure we are going to be in deep trouble in about five years time.

is offensive, at best. Moreover, unless Phil and his favorite browser vendors already have a solution in mind, and he anticipates that it will be objectionable to PKIX, this comment is gratuitous.

Since we're talking about how well browsers implement PKI mechanisms in the context of SSL/TLS, it is worth noting a presentation at last week's Black Hat conference in D.C. The presentation provided details on how several browsers remain vulnerable to attacks because they fails to check the Basic Constraints extension. This oversight of one of those pristine principles of PKIX ( we can use the acronym P3 going forward) and allows a web sites to act as a CA, based o the EE cert issued to it by any of the trust anchors embedded in the browser.

Another vulnerability, and matching MITM attack, is enabled by the issuance of certs that contain wildcard DNS names. This is not, a violation of P3, because PKIX caved to pressure from the TLS WG, to accommodate web site operators who wanted to purchase one cert from a TTP that could be used to verify the EE certs for multiple web sites. I argued against this, but lost. The phrase "I told you so" comes to mind :-).

So, contrary to Phil's assertion that adherence to P3 will get us into deep trouble in five years (with regard to this transition issue), I believe that PKI shortcuts (hacks) in browsers have gotten us into deep trouble for many years, and are likely to persist.

Steve