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

Hi Phillip,

On Feb 24, 2009, at 3:48 AM, <Pasi.Eronen@nokia.com> wrote:

> Phillip,
>
> Since you did suggest that adhering to "pristine principles of the
> PKIX infrastructure" would get us in deep trouble, does that mean you
> think relaxing/dropping some of those principles would allow us to
> avoid some of the trouble?
>
> Or in other words, what are you proposing? I'd certainly be interested
> in hearing it, even if it's not totally in line with how we've done
> things earlier...

I'll second Pasi's question.   If you are alluding to some particular  
proposal, I don't know what it is.

David

>
> Best regards,
> Pasi
>
> From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf  
> Of ext Hallam-Baker, Phillip
> Sent: 23 February, 2009 21:14
> To: Stephen Kent; saag@ietf.org
> Subject: Re: [saag] SHA-1 to SHA-n transition
>
> 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: saag-bounces@ietf.org on behalf of Stephen Kent
> Sent: Sat 2/21/2009 11:10 AM
> To: saag@ietf.org
> 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
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag