Broken SSL domain name trust model

[Anne & Lynn Wheeler]

leichter_jerrold at emc.com wrote:
> One can look at this in more general terms.  For validation to mean
> anything,
> what's validated has to be the semantically meaningful data - not some
> incidental aspect of the transaction.  The SSL model was based on the
> assumption that the URL was semantically meaningful, and further that any
> other semantically meaningful data was irreversibly bound to it, so that if
> the URL were valid, anything you read using that URL could also be assumed
> to be equally valid.
> 
> This fails today in (at least) two different ways.  First, as you point out,
> URL's are simply not semantically meaningful any more.  They are way too
> complex, and they're used in ways nothing like what was envisioned when SSL
> was designed.  In another dimension, things like cache poisoning attacks
> lead to a situationd in which, even if the URL is valid, the information
> you actually get when you try to use it may not be the information that was
> thought to be irreversibly bound to it.
> 
> Perhaps the right thing to do is to go back to basics.  First off, there's
> your observation that for payment systems, certificates have become a
> solution in search of a problem:  If you can assume you have on-line access
> - and today you can - then a certificate adds nothing but overhead.
> 
> The SSL certificate model is, I contend, getting to pretty much the same
> state.  Who cares if you can validate a signature using entirely off-line
> data?  You have to be on-line to have any need to do such a validation, and
> you form so many connections to so many sites that another one to do a
> validation would be lost in the noise anyway.
> 
> Imagine an entirely different model.  First off, we separate encryption
> from authentication.  Many pages have absolutely no need for encryption
> anyway.  Deliver them in the clear.  To validate them, do a secure hash,
> and look up the secure hash in an on-line registry which returns to you
> the "registered owner" of that page.  Consider the page valid if the
> registered owner is who it ought to be.  What's a registered owner?  It
> could be the URL (which you never have to see - the software will take
> care of that).  It could be a company name, which you *do* see:  Use a
> Trustbar-like mechanism in which the company name appears as metadata
> which can be (a) checked against the registry; (b) displayed in some non-
> alterable form.
> 
> The registry can also provide the public key of the registered owner, for
> use if you need to establish an encrypted session.  Also, for dynamically
> created pages - which can't be checked in the registry - you can use the public key
> to send a signed hash value along with a page.
> 
> Notice that a phisher can exactly duplicate a page on his own site, and it
> may well end up being considered valid - but he can't change the links, and he
> can't change the public key.  So all he's done is provide another way to get
> to the legitimate site.
> 
> The hash registries now obviously play a central role.  However, there are a
> relatively small number of them and this is all they do.  So the SSL model
> should work well for them:  They can be *designed* to match the original
> model.

this can basically be considered a form of extended DNS providing
additinal authentication ... secure DNS is one such proposal for
repository of public keys ... but the DNS model of online information
repository can be used for a variety of information.

this is also my oft repeated scenario of the ssl domain name
certification authorities needing secure DNS ... because when processing
an SSL domain name certificate request ... they have to check with the
domain name infrastructure as to the true owner of the domain name. this
currently is an expensive, time-consuming and error-prone process of
matching identification supplied with the request against identification
information on file with the domain name infrastructure. on the other
hand, if public keys of domain name owners were on file with the domain
name infrastructure ... the domain name infrastructure uses digitally
signed communication (validating with the onfile public keys) to
eliminate some of their existing integrity problems (which, then in
turn, improves the integrity of any ssl domain name certificate based on
information at the domain name infrastructure registry). the registered
public keys also allow the certification authorities to turn the
expensive, time-consuming and error-prone identification process into a
much less expensive, simpler, and more reliable authentication process
... by requiring ssl domain name name certificate requests to be
digitally signed by the domain name owner (and validated with the onfile
public keys).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com