Hal Finney wrote:
I thought of one possible mitigation that can protect OpenID end users
against remote web sites which have not patched their DNS. OpenID
providers who used weak OpenSSL certs would have to change their URLs
so that their old X.509 CA certs on their old URLs no longer work on the
new ones. This will require all of their clients (users who log in with
their OpenID credentials) to change their identifiers. DNS based MITMs
will not be able to forge messages related to the new identifiers.

Yeah, I considered this scheme. The problem is that it doesn't really help the relying parties, who can still be fooled into believing an existing user is returning (or a new one is arriving) from the original site. This is particularly a problem for Sun's OpenID Provider, which makes the additional assertion (out of band) that the user is a Sun employee. So, anyone can become a Sun employee, as of a few days ago.

This is why the lack of CRL checking in OpenID libraries is an issue.

Again, I see fixing the DNS as the path of least resistance here,
especially so since the end user is the one bearing most of the risk,
typically DNS is provided by an ISP or some other agency with a formal
legal relationship, and there is the possibility of liability on the
part of the lax DNS provider. Hopefully we will continue to see rapid
uptake of the DNS fix over the next few weeks.

In general, DNS is not fixable without deploying DNSSEC.

a) The current "fix" just reduces the probability of an attack. If attacker and victim have sufficient bandwidth, it can still be done in under a day.

b) There are many scenarios, mostly revolving around the use of wireless hotspots, where users are easily fooled into using a malicious DNS provider.

So, DNS patching is not, IMO, the real answer to this problem. Of course, the second scenario has been around forever, but is conveniently ignored when explaining why CRLs are not necessary (and all other things that rely on perfect DNS). All that's happened recently is we've made people who are sitting still just as vulnerable as travellers.

But increasingly we are all travellers some of the time, from a "how we get our 'net" POV. We really can't ignore this use case.



http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to