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

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

As it happens, what I was referring to is that I do not like the look of this scheme. It is an ugly hack. However I dislike the consequences of not addressing this issue up front rather more and I really don't see how a less hackish solution will serve.
 
Now I did get offended by the implication that we should not consider technical issues if they might offend people. As with an earlier case where a past Security AD blocked a necessary protocol change because it 'gave him a bad gut feeling'. While making decisions based on the examination of intestines was all the rage in ancient Rome, it should be avoided.
 
 
On the points you raise.
 
1) If a device is not connected to a communications network, then why would it need to establish a cryptographic communication security context?
 
The offline PKI argument is seductive, but when you get down to case analysis, the real purpose of PKI is to communicate. The security guarantees that are possible in the offline case will always be lower than can be achieved in the online case.
 
If the device is not connected to a network realtime then issues such as certificate status are going to be have to be handled by something that is online and can pass a satisfactory proof of trustworthiness on.
 
But in any case, the issues are entirely addressed by OCSP token stapling which is possible in SSL and S/MIME and any XML signature based protocol.
 
 
2) 'that because certain conditions hold now, they always will'
 
I do not understand the relevance. What the claim amounts to is asserting that because my prediction of the future might be falible, no precidtion can be made, all outcomes are equally likely.
 
You base strategy on your best knowledge of the current situation and your best faith prediction of the consequences. If someone wants to challenge that analysis they should provide new facts and/or argue that different consequences are likely.
 
We have long experience of what the world does when we tell it our view of what the best thing is from a security perspective - they ignore us do what they think is in their best short term interests.
 
 
3)  'that it is OK for browser software to silently make configuration  changes based on external stimulus and without the user's consent.'

Here you might have a point. But I am not certain. In any case it is an implementation detail. What degree of control end users have is a policy matter. Most users are entirely happy for Microsoft or McAfee to control security on their PC.
 
Kill switches are unfortunately necessary at times. What is important is not so much the existence of the kill switch as who is in control.
 
In this particular case the whole purpose is to put enterprises and CAs on notice that a change is going to be necessary and that they have to start planning for it right now without setting a premature termination date. All an enterprise need do to plan for the transition is to upgrade their internal CA and their Web servers before SHA1 is actually broken. 
 
One option would be to allow the end user (or system manager) to over-ride the suicide note - provided that an equally secure mechanism was used for the control channel. Another would be to allow local configuration of the suicide note issuer.
 
I am not to sure about the consequences for your internal CA. If the roots are embedded in the browser then why not expect them to be handled according to current best practice? If the roots are not embedded then you might as well treat them as self signed certificates and allow a per-site exception.
 
I am not actually a fan of turning off certificates. An HTTP connection that is secured to an untrustworthy key is still better from a security point of view than one that is en-clair. My consistent suggestion has been that any browser should accept any key to start SSL unless the user types in https:// at the command line. The only difference being that the browser should not tell the user that SSL is in use in primary chrome.
 
 
 
 
________________________________

From: Jeffrey Hutzelman [mailto:[e-mail]]
Sent: Wed 2/25/2009 11:29 AM
To: Hallam-Baker, Phillip; Stephen Kent; [e-mail]
Cc: [e-mail]
Subject: Re: [saag] SHA-1 to SHA-n transition



--On Monday, February 23, 2009 11:13:55 AM -0800 "Hallam-Baker, Phillip"
<[e-mail]> wrote:

> 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'

Yes, this sort of crack is offensive and counterproductive.  Knock it off.

If you have a proposal to make, then fine, make it.
Don't start off by deliberately attacking people who you think will oppose
your proposal, on the basis of arguments that haven't yet been made and
probably won't be.  _That_ is offensive.

So, by the way, is the "sacred cow" comparsion, to some folks.


Your actual proposal makes a number of very large assumptions, such as...


- that interactive Web browsers with access to stable storage and
  nearly-continuous access to the connected Internet are the only
  problem worth solving.

  Possibly true for your company, and other CA's, and browser vendors.
  Definitely _not_ true for the IETF.

- that because certain conditions hold now, they always will

  Definitely not true for anyone, outside of an extremely tightly
  controlled environment, and maybe not even then.

- that it is OK for browser software to silently make configuration
  changes based on external stimulus and without the user's consent.

  This is definitely not true, and will actively screw people if the
  browser vendors ever implement your proposal.  Suppose you distribute
  your so-called "suicide note", causing my browser to reconfigure itself
  (silently and without my consent) to disallow SHA-1.  Unfortunately,
  my entire enterprise PKI was based on SHA-1 certificates, and you have
  just thrown my organization into chaos, potentially costing billions
  of dollars.  Can you imagine the lawsuits when Microsoft does this to
  a major financial institution?  Can you imagine the economic impact
  when Microsoft does this to _every_ major financial institution?


-- Jeff