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

From: Stephen Kent <[email-masked]>
Date: Sat, 21 Feb 2009 11:10:03 -0500

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Feb 2009 18:07:09 -0800

At Sat, 21 Feb 2009 11:10:03 -0500,
> between folks in both PKIX and TLS, plus some browser experts from 

I should note that TLS 1.2 already has support for SHA-n, as
well as mechanisms for indicating that an implementation 
will accept these certificates. Deployment of 1.2 has been
minimal so far, but I'm not aware of any new protocol design
work that needs to be done here.

> cert issued to it by any of the trust anchors embedded in the browser.

I agree that this is a problem.

> I argued against this, but lost. The phrase "I told you so" comes to 

Can you briefly describe how this leads to MITM attacks? This is something
I haven't heard before.

Best,
-Ekr

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 22 Feb 2009 11:58:11 +0200

Hi Ekr, 

Stephen is referring to the nice presenation at the Black Hat conference,
see 
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Ma
rlinspike-Defeating-SSL.pdf

I don't think that there is anything new in there but the slide set provides
a nice sate-of-the-art summary and points to the importance of properly
designed user interfaces. On the latter issue I have also noticed that in
the IETF we used to say that user-interface aspects are outside the scope of
our work. This leads to totally ignoring the way how the user utilizes the
protocols we develop (even though I understand that we don't want to
standardize a particular interface itself). However, for the complete
solution the user experience is something really important. My recent
examples were user interface aspect matter are: authorization policies we
use in the SIP environment, SIP Identity/SIP Security, early warning
messages, all sorts of identity management solutions (although they are
mostly developed outside the IETF).

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Eric Rescorla
>Sent: 22 February, 2009 04:07
>To: Stephen Kent
>Cc: [email-masked]
>Subject: Re: [saag] SHA-1 to SHA-n transition
>
>> between folks in both PKIX and TLS, plus some browser 
>experts from the 
>> APP area.
>
>well as mechanisms for indicating that an implementation will 
>accept these certificates. Deployment of 1.2 has been minimal 
>so far, but I'm not aware of any new protocol design work that 
>needs to be done here.
>
>> 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.
>
>Can you briefly describe how this leads to MITM attacks? This 
>is something I haven't heard before.
>
>Best,
>-Ekr
>_______________________________________________
>saag mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/saag
>

---

From: Stephen Kent <[email-masked]>
Date: Sun, 22 Feb 2009 20:53:04 -0500

At
>...

Look at the latter half of these slides for his description of the 
role that wildcard DNS names on certs play in one class of attacks.

<https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>

Steve

---

From: "Chandersekaran, Coimbatore S" <[email-masked]>
Date: Mon, 23 Feb 2009 12:08:56 -0500

Cannot connect to the site. Get a 404  error. Can someone post this deck to SAAG? 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hannes Tschofenig [[email-masked]]
Sent: Sunday, February 22, 2009 4:58 AM
To: 'Eric Rescorla'; 'Stephen Kent'
Cc: [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

Hi Ekr,

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Feb 2009 10:03:17 -0800

At Sun, 22 Feb 2009 20:53:04 -0500,
> <https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>

This gets me a 404 as well.

-Ekr

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Feb 2009 10:40:23 -0800

The basic attack was to obtain a domain name in a zone that does not have I18N homograph protection on by default (e.g. example.cn) then look for a homograph character for /
 
Then set a domain name http://anysite.com/padding/.example.cn/ which will bind to a wildcard. Where com/padding/ is actually a single DNS label with two lookalikes for / in it.
 
The same thing is done today with http://anysite.comlpaddingI.example.com/

However the presenter is not entirely correct in his claims
 
* The wildcard attack does not affect EV as claimed as wildcards are prohibited in EV certs. 
* Contrary to the presenter's claims, there is nothing that obligates him to release exploit code
* The presenter fails to mention that at least one of the sites he uses as an example of a password submission form on an unprotected page has not been configured that way for over two years, point of that example seems to have been that he got himself on TV.
* No mention at all of the W3C Web Security Context Working Group that was set up to make recommendations on these UI issues and currently has a document about to enter last call.
 
All in all, folk who are watching presentations on social engineering exploits should always ask themselves who is being socially engineered and for what purpose.

________________________________

From: [email-masked] on behalf of Eric Rescorla
Sent: Mon 2/23/2009 1:03 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

-Ekr

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Feb 2009 11:13:55 -0800

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: [email-masked] on behalf of Stephen Kent
Sent: Sat 2/21/2009 11:10 AM
To: [email-masked]
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.

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Feb 2009 22:08:22 +0200

Does this help?

http://tinyurl.com/d4gons
________________________________________

-Ekr

Email secured by Check Point

---

From: <[email-masked]>
Date: Tue, 24 Feb 2009 12:48:53 +0100

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

Best regards,
Pasi

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Hallam-Baker, Phillip
Sent: 23 February, 2009 21:14
To: Stephen Kent; [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

Steve

---

From: David McGrew <[email-masked]>
Date: Tue, 24 Feb 2009 04:12:07 -0800

Hi Phillip,

> in hearing it, even if it's not totally in line with how we've done

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

David

> 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:
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
> 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 :-).
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Feb 2009 07:02:04 -0800

OK, traditionally, PKIX is based on a Kohnfelder style certificate architecture. At the time (1977) it was believed that it was impractical to run a directory of keys, or update keys frequently. The Internet such as it was ran at dial up speeds.
 
Since then a number of things have happened
 
1) The original monolithic PEM root was replaced with a heterachy.
2) CRLs became too big to be useful for large CAs.
3) Network connectivity became dependable and ubiquitous.
4) OCSP began to be used as the default revocation checking mechanism (vista).
 
What I think we need to do is to create an insurance policy that uses the OCSP token as a fallback certificate mechanism as follows:
 
1) Client software authors create a Rivest style 'suicide note' for the SHA1 algorithm (OK he did it just for certs, this is for algs, same idea).
1a) They chose a random number x which is appropriately sequestered.
1b) They generate the witness value W = SHA1(x) 
1c) Code in the browser recognizes a suicide note as being authentic if it contains a value x such that SHA1(x) = W
1d) If the suicide note is delivered the browser will henceforth not accept a certificate if the authentication chain is dependent on SHA1.
 
2) A legacy browser may still make use of a SHA1 authenticated certificate, provided that it can obtain an alternative certification route via an acceptable digest in the OCSP token.
2a) Client asks for an OCSP token signed with SHA2
2b) Server returns token signed with SHA2 and contains a digest of the original cert in SHA2
 
[Hold your horses on efficiency grumbles, OCSP stapling, short lived certs can be used]
[Oh and yes, do the same for all algorithms]

OK so that meets our security requirements, it allows a browser to be delivered today that works with existing SHA1 certificates right up until the moment that it is deemed no longer safe to use SHA1.
 
So for example, let us imagine that we deployed this scheme on the day that the SHA1 problems were first uncovered. At that point the population of Web browsers would be:
 
[The SHA2 browser supporting SHA1 via a suicide note scheme, ditto for SHAn so total is more than 100%]
 
SHA1: 100%
SHA2: 0%
SHAn: 0%
 
So if SHA1 was compromised then, every browser in creation would have to be upgraded which would be a party for the attackers since they are very good at exploiting chaos and in particular transition arrangements. Every time a bank merges they send out phishing attacks.
 
Now lets wind forward to maybe where we will be in a few years:
 
SHA1: 100%
SHA2: 50%
SHAn: 5%
 
At this point SHA1 is still deemed to be acceptably secure, there is a large population of SHA2 browsers. But any site that buys a SHA2 certs would automatically lose half their business and they are not going to do that. This is the problem with algorithm transitions.
 
Now lets wind forward to where I would hope we are when SHA1 starts to look really bad, let us imagine that we have a collision attack but not a first pre-image, lets also imagine that we have an acceptable amount of randomness to foil exploits:
 
SHA1: 30%
SHA2: 80%
SHAn: 20%
 
The suicide note has been delivered. We are worried anough about the security of SHA1 to require CAs to deliver SHA2 validated tokens. But even so there is a significant proportion of browsers using SHA1 and businesses want to continue to use.
 
At this point, there will of course be some people saying cut the old browsers lose, but that will create chaos that the criminals will exploit. Better to withdraw the old algorithm gradually. 

Now compare this withdrawal scheme with what happens if you try to do a hard cut-over. This time the decision is made by the browser provider and the significant quantity is the number of certificates in the population. In particular, remember that CAs will sell what their customers demand and their customers will demand certificates that work with the greatest number of browsers and no browser provider can cut over if the proportion of SHA1 certs is greater than 50%
 
So on day 1 the population of certs is:
 
SHA1: 100%
 
Therefore every browser must support SHA1 and every business will buy an SHA1 cert, so on day 2 the population of certs will be 
 
SHA1: 100%
 
Therefore every browser must support SHA1 and every business will buy an SHA1 cert, so on day n+1 the population of certs will be 
 
SHA1: 100%
 
The induction goes on forever. The only way to escape it is to create a bifurcated transition path so that new browsers can take advantage of better security without impacting the old.

On the efficiency issue, there are two possible fixes. The simplest is to deploy OCSP token stapling in SSL so that a browser gets a token and cert chain all in one go. 
 
Another possibility is to create short lived certs and provide a selection mechanism. This is more expensive in bits however as two complete cert chains are required.

So in conclusion, we can manage this transition, but only if we first abandon the foolish notion that people are going to do the right thing of their own accord. Even though every party in this system is aware of the right thing, none is able to do it because the business imperative is to keep the system running one more day.
 
Looking at the deployed infrastructure, the simplest fix to me is to use the OCSP path. Note that this does effectively turn PKIX into a key centric model PKI. The cert chains are then isomorphic to XKMS.

From: [email-masked] [mailto:[email-masked]]
Sent: Tue 2/24/2009 6:48 AM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: [saag] SHA-1 to SHA-n transition

Phillip,

 
Best regards,
Pasi

	 

	 

	 

	Steve

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 25 Feb 2009 11:29:30 -0500

--On Monday, February 23, 2009 11:13:55 AM -0800 "Hallam-Baker, Phillip" 
<[email-masked]> 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:

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Feb 2009 09:37:33 -0800

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:[email-masked]]
Sent: Wed 2/25/2009 11:29 AM
To: Hallam-Baker, Phillip; Stephen Kent; [email-masked]
Cc: [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

-- Jeff

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 25 Feb 2009 13:54:33 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
	Sent: Wednesday, February 25, 2009 12:38 PM
	To: Jeffrey Hutzelman; Stephen Kent; [email-masked]
	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.

	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.

	 

	--On Monday, February 23, 2009 11:13:55 AM -0800 "Hallam-Baker,
Phillip"
	
	> * 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.

	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.

	  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

---

From: der Mouse <[email-masked]>
Date: Wed, 25 Feb 2009 14:46:47 -0500 (EST)

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

I don't know the particular case you're talking about, nor do I really
want to, so I specifically want to avoid commenting on that case.  But
I would hesitate to summarily write off the gut feeling of someone
experienced, which is more or less what I read your second sentence as;
much of what experience _is_ amounts to training one's gut feeling.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Feb 2009 14:02:27 -0800

We have a choice here.
 
Either we have a debate in which people bring up rational technical points or we have a free for all in which people claim a privileged position that allows them to block any proposed change to the status quo without giving a technical reason that can be challeged.
 
My gut is telling me that we have a very serious problem that is going to bite us down the road. And I can give solid technical reasons to back that feeling.
 
We have the same set of arguments whenever someone suggests that the IETF consider practical deployment issues. It is never the right time to raise these issues and they are never raised in the right way.

Let us stick to the technical issues here:
 
* Is the current transition plan viable or does it fail in the way that I predict
* Is the proposed solution viable?
* Is there a better solution?

From: [email-masked] on behalf of der Mouse
Sent: Wed 2/25/2009 2:46 PM
To: [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

/~\ The ASCII                             Mouse
\ / Ribbon Campaign

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Feb 2009 14:43:33 -0800

>* Is there a better solution?

None of those are technical issues.

--Paul Hoffman, Director
--VPN Consortium

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Feb 2009 18:19:42 -0500

Hi,
 
I find it rich that you started this thread by being offensive, and
now you want
"

If you want people to listen to you and discuss technical arguments,
maybe you should learn to introduce the topics in a less offensive
manner.
 
If people do not want to have this discussion with you at this time,
you have only yourself to blame.
 
David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Feb 2009 17:35:04 -0800

I was intending to raise a serious technical point. If the comment might have been interpreted as offensive it is because it might be interpeted as a suggestion that people would be more interested in debating a distraction than the technical issue. 

Can we please stop the agenda denial tactics and talk about the fact that we may have a serious problem?
 
Currently the industry is taking for granted the idea that merely distributng browsers that support stronger crypto algorithms is sufficient to support a transition when that becomes necessary. But when serious attention is paid to the business issues that drive the purchase of certificates it is clear that this strategy is not going to result in the withdrawal of support for SHA1 certificates until the population of browsers that support only SHA1 is negligible. That will take at least a decade, possibly much longer.
 
If people really think that Amazon.com is going to say 'I know that only 95% of browsers support SHA1, but I am going to get an SHA2 cert and lose that 5% of sales so that our transactions are as secure as possible' because someone finds a practical attack on SHA1, then let them say that. So far nobody has challenged the analysis directly, they have merely described themselves as unconvinced that there is a problem.

From: David Harrington [mailto:[email-masked]]
Sent: Wed 2/25/2009 6:19 PM
To: Hallam-Baker, Phillip; 'der Mouse'; [email-masked]
Subject: RE: [saag] SHA-1 to SHA-n transition

Hi,
 
I find it rich that you started this thread by being offensive, and now you want
"

	If you want people to listen to you and discuss technical arguments, maybe you should learn to introduce the topics in a less offensive manner.
	 
	If people do not want to have this discussion with you at this time, you have only yourself to blame.
	 
	David Harrington
	[email-masked]
	[email-masked]
	[email-masked]

---

From: Michael O'Neill <[email-masked]>
Date: Thu, 26 Feb 2009 10:47:18 +0000

David Harrington wrote:

Hi,

I find it rich that you started
this thread by being offensive, and now you want

"

Let us stick to the
technical issues here:

If you want people to listen to
you and discuss technical arguments, maybe you should learn to
introduce the topics in a less offensive manner.

If people do not want to have
this discussion with you at this time, you have only yourself to blame.

David Harrington

[email-masked]

[email-masked]

[email-masked]

Hi

Focus furthers aims.

Short term focus fails long term.

'Ware the focus freaks.

Michael O'Neill

---

From: Theodore Tso <[email-masked]>
Date: Thu, 26 Feb 2009 09:38:09 -0500

On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker, Phillip wrote:
>  
> If people really think that Amazon.com is going to say 'I know that
> only 95% of browsers support SHA1, but I am going to get an SHA2
> cert and lose that 5% of sales so that our transactions are as
> secure as possible' because someone finds a practical attack on
> SHA1, then let them say that. So far nobody has challenged the
> analysis directly, they have merely described themselves as
> unconvinced that there is a problem.
>  

OK, so let's get real here.  The reality is that transitioning between
crypto algorithms is *hard*, and that the tragedy of the commons is
hitting us hard.  We can try to create technical solutions (such as
the Svengali-style suicide note which causes browsers to break
intranets), but their have shortcomings because this is fundamentally
a social problem.

There are couple of things we need to do in order to successfully
carry off a migration:

(1) We need to get browsers to add support for the new crypto algorithm
(2) We need to get users to upgrade to the new browsers with support
	for the new crypto algorithm
(3) Once (1) and (2) are done, we need to get secure commerce sites to
	upgrade to use certificates that utilize the new crypto algorithm.
	(In practice this will be the crypto checksum; but the same thing
	applies if we ever need to get nervous about replacing the PK
	algorithm.)

This normally takes time --- years, but it is possible to speed things
up.  For example, an interested body, perhaps funded by far-sighted
merchants and other concerned citizens, could track which browsers
have added the new algorithms, and jawbone (and perhaps in the later
part of the effort, publically shame) entities distributing browsers
to implement the new algorithm.

For (2), sites who were interested in being "good citizens" could test
to see if the browser supports the new crypto algorithm, and display a
"nag screen" if the browser apparently doesn't support the new crypto
algorithm.  Said nag message could be gentle at first, but could get
increasingly strident; a lot of this would be up to the web site(s)
involved, of course.

So it's possible to encourage the ecosystem to move in a particular
way, but it all requires effort and coordination, and the tragedy of
the commons is that until the emergency comes up, it's unlikely that
such an effort will get funding and support.  

But again, this is all nothing new, and I suspect one of the reasons
why we're thrashing a little in this discussion is because it really
is much more of a social problem than a technical problem, which means
it's a bit outside of the IETF's core competency.

					- Ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Feb 2009 07:33:21 -0800

Ted,
 
Thanks for the comments.
 
I agree that this is really hard, but I do not think that tragedy of the commons is a good analogy. This is not a resource depletion issue. This is more like a prisoner's dilema issue in which following their own best short term interests causes everyone to end up with a worst-case result. Unlike the Axelrod prisoner's dilema, the problem does not go away when the game is played repeatedly. On the contrary the deadlock becomes tighter.
 
The reason that this is our problem is that the standards establish the set of options available to the parties and the values of the outcomes.
 
The good part is that if we can understand this issue and work out a systematic theory of how to address it we have a key that can unlock the deployment of other protocols - IPv6, ubiquitous IPSec, ubiquitous email encryption and so on.

We have encountered deployment deadlock in various forms in many different protocols. We have a lot of experience of deployment deadlock but no systematic theory. I think that we can develop an adequate theory for the purposes of protocol design by borrowing some ideas from the economists, in particular rational choice theory.
 
In rational choice theory we model the behavior of each party by *assuming* that they will follow their exclusive best interests. 
 
I emphasize the word assume here as it is merely a modelling assumption and not a factual claim or a normative ethic. I do not want to get into a distraction about whether the Rat Choice modelling assumption is a normative truth. We are merely using it here as a modelling assumption, we do not need to enter into a politcal digression. While it is very clear that some people act from altruistic motives on some occasions, and we could model this, it is necessary to assume an improbable degree of altruism to affect the outcome.

What I did was to identify the parties:
 
1) Web browser providers
2) Certificate Authorities
3) Merchants
 
I am using merchants as a subset of certificate holders to simplify matters. While it may be argued that other certificate users will behave differently, the merchants are a large enough subset that their actions are sufficient to determine the behavior of the CAs.
 
Note that these parties are listed in a particular order. The IETF has the greatest ability to communicate with the Web browser providers, somewhat less contact with CAs and has negligible contact with the merchants. As a pragmatic matter it is much easier to change IETF specs than to mount an Al Gore publicity campaign telling folk to move to SHA-n. And in any case we have a very limited amount of jawboning bandwidth and we have to use that as a last resort. I would much rather have Vint Cerf jawboning carriers into support for IPv6.
 
>From a business perspective, the actions are determined in the reverse order. The CAs are driven by the demands of their customers. If any CA attempts to behave altruistically by refusing to supply a product demanded by the merchants they will lose business. In practice the actions of the Web browser providers are driven by the facts on the ground in the same way.
 
The facts on the ground in question are
 
1) The amount of business that merchants receive from browsers that do not support SHA-n
2) The number of merchants who deploy SHA-n certificates
 
We have some influence on the first factor but almost no influence on the second. At this point it is reasonably clear that the browser providers are either supporting SHA2 today or will do so in the very very near future. If not they risk public shame every time RSA and Crypto come round.
 
My problem is that based on my experience of the merchants, I cannot see any merchant voluntarily chosing a SHA-n certificate that provides only (100-x)% coverage while there is a SHA-1 certificate on offer that gives 100% for values of x greater than 2. No business is going to voluntarily sacrifice even 1% of sales for a security issue that only affects the credit card issuers.
 
And there is no way for the browser providers to withdraw support for SHA1 if 90% or more of merchants are using SHA1 certs. Not without proof-positive that an actual break has occured which by definition means that we are too late. And even then it will take several years for the SHA1 capable browsers to be withdrawn from service and those will still be vulnerable in the interim.

That is a deployment deadlock.

From: Theodore Tso [mailto:[email-masked]]
Sent: Thu 2/26/2009 9:38 AM
To: Hallam-Baker, Phillip
Cc: David Harrington; der Mouse; [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

                                        - Ted

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 Feb 2009 07:58:37 -0800

On Thu, 2009-02-26 at 09:38 -0500, Theodore Tso wrote:

> (1) ...
> (2) ...
> (3) Once (1) and (2) are done, <deploy certs using sha-n>

So, that sort of transition plan is doomed.  (1) and (2) will never be
"done" because there will always be sites and clients running old
software.

What's more, software which has not been tested does not work.  We don't
know until we start trying to deploy sha-n certs on a wide scale if we
got all the details right, and if we got something wrong and have to
tweak the browsers again...

IMHO we need a transition plan which allows websites to deploy with
sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare
mention it, we need to find some way to do this without making them pay
a bunch of nuisance fees to CA operators).

That way the hard part of the transition plan looks more like:

 n) release software which expects sha-n and considers sha-1 an
exceptional case.

and the triggering event for this can be somewhat more flexible.  It may
still happen shortly after a "cnn moment", but which would be a much
more graceful transition than if we had to throw the switch starting
today.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Feb 2009 08:04:54 -0800

Lets not debate the semantics of what is and is not a technical issue.
 
They are the issues that are critical to deployment of a successful transition. Since we are (mostly) the people who care most about this particular transition, it is up to us to understand the problem and find a solution.

So far the only real objection is to the implementation of the suicide note. And what I am proposing is not really a suicide note in the manner proposed by Rivest and Lampson. I am merely re-using his idea of a self-authenticating statement that a key is no longer safe to use and applying it to make a similarly secure statement about an algorithm. The name seems to be distracting.
 
So lets call it a 'upgrade-available' note which is a closer description in this case.
 
How about this as a mechanism:
 
* 'Upgrade-available' Note is established on a per CA-Root basis.
* Each CA determines when they have full support deployed for OCSP back-up authentication.
* CA issues the 'Upgrade-available' note for their particular roots.
* Henceforth browsers know that if they see a SHA1 cert they should check for a SHAn OCSP token.
* This mechanism is only enabled if the user has turned on OCSP validation.
 
Binding the note to the particular root should avoid Jeff's issue. It also removes the need for the CAs to move en-masse which is probably a good thing but I will have to run some simulations to work out if that is the case.

This seems defensible to me. If I am the CA that stands behind a certificate, I can tell people when it might be appropriate to perform additional checks to make sure that a certificate is really valid.
 
If an enterprise is running its own CA it can make its own decision as to when to tell capable browsers to use SHAn.

From: [email-masked] on behalf of Paul Hoffman
Sent: Wed 2/25/2009 5:43 PM
To: [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

--Paul Hoffman, Director
--VPN Consortium

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Feb 2009 08:05:37 -0800

The need to test code paths is a really good point.
 
It might mean that we would want to avoid a hard-switchover.
 
But then it is hard to create a soft landing.

From: Bill Sommerfeld [mailto:[email-masked]]
Sent: Thu 2/26/2009 10:58 AM
To: Theodore Tso
Cc: Hallam-Baker, Phillip; der Mouse; [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Feb 2009 10:54:48 -0600

> a bunch of nuisance fees to CA operators).

Indeed.  And not having to pay "nuisance fees to CA operators" falls out
of not having a real PKI -- no real PKI, no real CAs to pay.

What we need is something like DIGEST-MD5, but tied into browser apps in
a different way than DIGEST-MD5 is today (more on this below).  Given
this we can forego PKI -- just do channel binding to TLS (with or
without server certs, whether CA-issued or self-signed).

My proposal:

1) Add JavaScript interfaces to deal with DIGEST-MD5, successors,
   GSS-API, ...

   These could be simple XmlHttpRequest object extensions, where
   DIGEST-MD5 can already be used, and where HTTP/Nego and successors
   could be used too.

2) Tie the above interfaces to the browser UI.

   Mark pages/windows/tabs with colors/text/sound/whatever appropriate
   markers as:

    - plain (nothing is authenticated)
    - weak server authentication (what we do today with HTTPS)
    - mutually authenticated (DIGEST-MD5/something else was used through
      the above mentioned interfaces, with credentials furnished through
      the trusted path)

   Add markers for degree of security based on crypto algs used.

   Make it simple for users to see the authenticated identities.

   We'll also need a new flavor of cookies.  We have "secure" and "not
   secure" cookies now; we'll need "issued in mutually authenticated
   context" -- call them "authenticated cookies."

   Prompting for DIGEST-MD5/whatever credentials needs to be done
   securely.

   As with all UI design matters, it's important to find a way to
   prevent attackers from emulating the UI with enough fidelity.  (E.g.,
   don't allow full-screen apps.)

3) Teach users to look for the new markers.  *This* is the hard part.
   Education will always be the hard part.

   (Not that UI design isn't hard -- it is, and it is a requirement to
   get the UI right if we're to educate users successfully.)

4) Federation/whatever fits into (2).  We already have lots of
   federation choices.  The propblem is how federation fits in
   generally.

Given (1), (2) and (3) the transition to SHA-n looks a lot simpler: it's
completely piecemeal, there's no CAs to shame into getting SHA-n support
because PKI gets cut out of the picture (even if server certs are still
used, they no longer matter for security).  TLS would still be used, so
getting TLS implementations updated to 1.2 so that SHA-n would be a
requirement.  As would be a successor to DIGEST-MD5.

We'd also be solving some of the other web security problems with this
approach.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Feb 2009 15:20:06 -0500

Nico, while I'm in favor of channel binding and believe your approach
has a lot of value, please be careful to apply it only where applicable.

Phil is talking about the web browser PKI.  Channel binding to
existing authentication solves some problems in that space, but
definitely not all.  For example it is not useful for securing
enrollment or certain classes of URI-only handoff.

So, I think the web will continue to need a PKI.:-)

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Feb 2009 14:36:33 -0600

> So, I think the web will continue to need a PKI.:-)

A PKI that does not exist.  Channel binding is not a silver bullet, and
in this case one could argue it ought not have a place.  But given what
we have to work with it seems like it can actually help.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Feb 2009 13:03:31 -0800

Without wanting to go too far down this route. 
 
Yes the approach has merit and one can even imagine a situation in the distant future where this type of approach transforms the role of CAs rendering certain types of low assurance product obsolete. But what you cannot get from that approach alone is a demonstration of accountability which is the cornerstone of the Extended Validation design.
 
And even if we start right now, such a scheme requires deployment of a whole new infrastructure and a whole new set of applications to run on top of it.
 
While I certainly hope that it takes the cryptographers as long to turn the SHA1 querry into a full break as it took them to convert the MD5 compromise into a fuill break I do not want to depend on that. And I certainly think that we, the crypto-security community are going to be nervous about the security of SHA1 long before the rest of the industry is.

And even if such an infrastructure was deployed, the CAs wil still be in business selling DV validated certs because there will still be a large number of businesses that make support for legacy browsers a much higher priority than not supporting crypto algorithms that make us nervous. 

From: [email-masked] on behalf of Sam Hartman
Sent: Thu 2/26/2009 3:20 PM
To: Nicolas Williams
Cc: der Mouse; [email-masked]
Subject: [saag] Channel binding is great but not a silver bullet

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Feb 2009 18:23:59 -0800

At Thu, 26 Feb 2009 10:54:48 -0600,
>    get the UI right if we're to educate users successfully.)

I don't want to get into an extensive argument about this on SAAG,
but I don't think this direction is particularly promising, for
reasons I've indicated before: namely that you're handwaving
the difficult part of the problem, UI, which we have no real 
idea how to solve. Sure, if we solved that, there are any
number of things we could do, but absent that, the other things
are fairly useless.

> requirement.  As would be a successor to DIGEST-MD5.

I think you're rather overselling here: this only works well for
account-based systems. There are plenty of cases where I need to
connect to someone where I only know their name but I don't yet have
an account (e.g., https://www.amazon.com). The mechanism that you
provide doesn't work at all in this case. Rather, you need some
third-party verifiable mechanism. I suppose one could argue that certs
aren't a good such mechanism, but they're the one that TLS supports
and I suspect any replacement would smell a lot like certs.

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Feb 2009 21:55:54 -0600

> and I suspect any replacement would smell a lot like certs.

This is quite true.  I did not address enrolment, nor cases where there
is simply no relationship to be had.  A PKI would sure be nice; I just
don't believe we'll have something very close to one.

Regardless of what we do we're likely to just muddle through in the end.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 27 Feb 2009 19:56:12 +1300

Nicolas Williams <[email-masked]> writes:

>What we need is something like DIGEST-MD5, but tied into browser apps in a
>different way than DIGEST-MD5 is today (more on this below).  Given this we
>can forego PKI -- just do channel binding to TLS (with or without server
>certs, whether CA-issued or self-signed).

We already have this, and have had for some years, it's called TLS-PSK.
Unfortunately the browser vendors' approach is to keep on waiting for PKI to
start working, forever if necessary.  "PKI meurt, elle ne se rend pas!" [0].

Peter.

[0] Hat tip to Luther Martin for the quote :-).

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 27 Feb 2009 05:35:23 -0800

We have a PKI. We have had a PKI for fifteen years. Its just a PKI that requires people to pay for service. 

If the only PKI that counts is a completely free at point of delivery PKI then I guess that we don't have a DNS system either since the NSF decided to start charging.

What you mean is that a completely free to use PKI would be nice.

We actually have one of those, SSH works quite nicely for what it does. Just not for assuring potential customers that a credit card transaction is safe for them.

Problem is that there are some tasks that really don't work as community efforts. Auditing and preparing taxes for example. If folk work out how to make those work on an open source type model we could maybe try a CA.

What we need to do here is to fix the PKI that we have already deployed and is serving a million Web merchants. Or rather, take out an insurance policy in case we need to fix it at short notice.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 27 Feb 2009 05:41:01 -0800

EKR, 

I would like to dispute one small part of this. I think we do know something about UI.

A UI works if the user has to do absolutely nothing to be secure. The more that a user is required to do, the less likely they are to do it correctly.

Since we cannot expect the end user to know SHA1 or SHA2 from a potato we cannot present the typical user with any UI change whatsoever. End of story.

We can put some options in for the expert user, but we probably don't want those to be too easy to get at.

-----Original Message-----
From: [email-masked] on behalf of Eric Rescorla
Sent: Thu 2/26/2009 9:23 PM
To: Nicolas Williams
Cc: der Mouse; [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

-Ekr