Security team successfully cracks SSL using 200 PS3's and MD5

Mon Jan 5 22:41:29 UTC 2009

On Tue, Jan 06, 2009 at 06:09:34 +0900, Randy Bush wrote:
> to use your example, the contractor who serves dns for www.bank.example 
> could insert a cert and then fake the web site having (a child of) that 
> cert.  whereas, if the site had its cert a descendant of the ca for all 
> banks, this attack would fail.

To be pedantic, it'd have to be the contractor who holds the signing
key for the bank.example zone (which may be a separate entity from
whoever has operational control of the nameservers).

You're correct that this proposal treats control of a DNS zone as a
strong proof of identity, but I'd argue that that's the case already --
whoever controls the zone can easily get a CA to issue them a cert
which is valid for the host "www.bank.example".  Whether the
organization name is "Example Bancorp" or "DomainSquatters'R'Us, Inc."
is irrelevant, since nobody ever looks at that.

I'd go so far as to argue that the hostname is the proper *definition*
of identity in this context.  The client identifies the destination it
wishes to connect to by hostname, not by organization name.  The
purpose of the cert ought to be to ensure that we're talking to the
host identified by that hostname (according to a necessarily trusted
DNS).

Ensuring that the hostname belongs to someone the user really wants to
speak to is an orthogonal problem which is impossible to solve without
a clueful user in the loop, and at which the current model is failing
miserably.