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

["Santosh Chokhani" <[e-mail]>]

Has any one seen the DSSC I-D from LTANS WG on checking for acceptable
algorithms.
 
I also find that migration from SHA1 to SHA 256 will not be as painful,
albeit not all spec have it and they need updating.
 
I say this because there is no pre-image attack on the horizon, changing
the algorithm some time before SHA1 compromise keeps the infrastructure
secure without fear of contamination.
 
I have found Phillip's OCSP argument as a solution looking for problem.
When he published his first draft on this in PKIX, WG I provided him
extensive comments.  Many of my misgivings still remain.


________________________________

	From: [e-mail] [mailto:[e-mail]] On
Behalf Of Hallam-Baker, Phillip
	Sent: Wednesday, February 25, 2009 12:38 PM
	To: Jeffrey Hutzelman; Stephen Kent; [e-mail]
	Subject: Re: [saag] SHA-1 to SHA-n transition
	
	
	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