[cap-talk] Re: Broken SSL domain name trust model

[Ian G]

This proposal is more or less similar to that of
the 'secure bookmarks' of Marc Stiegler which is
essentially a nice metaphor for the YURLs of
Tyler Close which is essentially a packaging of
capabilities in URLs from the entire school of
POLA/caps.

These guys all hang out at cap-talk.  It was out
of that school that Petnaming was developed, the
innovation that is in the Petname toolbar and
Trustbar (independantly) and has been since 2004
and remains the great white hope against phishing.

Oddly enough that forum has been rattling like
mad on this very idea for the last two weeks.  And
Pelle has also knocked up a facsimile of this at
https://wideword.net/ .  It may be that the time
of the 'secure boomkark' has arrived.

iang


Anne & Lynn Wheeler wrote:
> 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
>