Broken SSL domain name trust model

Anne & Lynn Wheeler lynn at garlic.com
Mon Nov 28 06:39:10 EST 2005


so this is (another in long series of) post about SSL domain name trust
model
http://www.garlic.com/~lynn/2005t.html#34

basically, there was suppose to be a binding between the URL the user
typed in, the domain name in the URL, the domain name in the digital
certificate, the public key in the digital certificate and something
that certification authorities do. this has gotten terribly obfuscated
and looses much of its security value because users rarely deal directly
in actual URLs anymore (so the whole rest of the trust chain becomes
significantly depreciated).

the contrast is the PGP model where there is still a direct relationship
between the certification the user does to load a public key in their
trusted public key repository, the displayed FROM email address and the
looking up a public key using the displayed FROM email address.

the issue isn't so much the PGP trust model vis-a-vis the PKI trust
model ... it is the obfuscation of the PKI trust model for URL domain
names because of the obfuscation of URLs.

so one way to restore some meaning in a digital signature trust model is
to marry some form of browser bookmarks and PGP trusted public key
repository. these trusted bookmarks contain both some identifier, a url
and a public key. the use has had to do something specific regarding the
initial binding between the identifier, the url and the public key. so
such trusted bookmarks might be

1) user clicks on the bookmark, and a psuedo SSL/TLS is initiated
immediately by transmitting the random session key encrypted with the
registered public key. this process might possible be able to take
advantage of any registered public keys that might be available from
security enhancements to the domain name infrastructure

2) user clicks on something in the web page (icon, thumbnail, text,
etc). this is used to select a bookmark entry ... and then proceeds as
in #1 above (rather than used directly in conjunction with a URL and
certificate that may be supplied by an attacker).

there are other proposals that try and collapse the obfuscation between
what users see on webpages and the actual security processes (trying to
provide a more meaningful direct binding between what the user sees/does
and any authentication mechanism) ... but most of them try and invent
brand new authentication technologies for the process.

digital signatures and public keys are perfectly valid authentication
technologies .... but unfortunately have gotten terribly bound up in the
certification authority business processes. the issue here is to take
perfectly valid digital signature authentication process ... and create
a much more meaningful trust binding for the end-user (not limited to
solely the existing certification authority and digital certificate
business models).

the issue in #2 is that the original electronic commerce trust process
was that the URL initially provided by the user (typed or other means)
started the trust process and avoided spoofed e-commerce websites. one
of the problems has been that the SSL security has so much overhead,
that e-commerce sites starting reserving it just for payment operation.
As a result, users didn't actually encounter SSL until they hit the
checkout/pay button. Unfortunately if you were already at a spoofed
site, the checkout/pay button would have the attacker providing the
actual URL, the domain name in that URL, and the SSL domain name
certificate.

so the challenge is to drastically reduce the obfuscation in the
existing process ... either by providing a direct mechanism under the
user control for getting to secure websites or by doing something that
revalidates things once a user is at a supposedly secure webstie.

the issue is that if users start doing any pre-validation step and
storing the results ... possibly something like secure bookmarks ...
then it becomes farily straight-forward to store any related digital
certificates along with the bookmark entry. if that happens, then it
becomes obvious that the only thing really needed is the binding the
user has done between the public key in the digital certificate and the
bookmark entry. at that point, it starts to also become clear that such
digital certificates aren't providing a lot of value (being made
redundant and superfluous by the trust verification that the user has
done regarding the various pieces of data in the entry).

in effect, the PKI model is based on premise that it is a substitute
where the relying party isn't able to perform any trust
validation/operations themselves (i.e. the letters of
credit/introduction model from the sailing ship days). when the relying
parties have to go to any of their own trust operations, then there is
less reliance and less value in the trust operations performed by
certification authorities.

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



More information about the cryptography mailing list