Re: A secure Internet requires a secure network protocol

[Anne & Lynn Wheeler]

Alex Alten wrote:
SSL seems to be hanging by a thread, mainly the name to public key mapping
depends on how thorough the checking is done in to SSL vs application 
layers
inside of the web browser.  If this is hosed then unrestricted MITM is 
in the cards
sometime in the near future.

re:
http://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure 
network protocol

i.e. we were called in to consult with this small client/server startup that 
wanted
to do payments on their server. they had this technology they called SSL ... 
and we
had to end-to-end process audits ... including walk-thru of some of these new 
business
entities that were calling themselves certification authorities.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the fundamental SSL design point was that the user knows the relationship 
between a website
and a URL, the user entered that URL, and SSL would authenticate that the 
website that
the user *thot* they were talking to (from entering the URL), was in fact, the 
website
they were actually talking to.

these days, most users have no cognition about relationship between websites and URLs, 
they click on something in email and/or webpages. In this scenario, the attacker
is providing the URL and then the only thing that SSL is providing is 
authenticating
who the attacker is claiming to be (via the URL that the attacker provides).

the original SSL design point had implicit assumptions that users knew the 
relationship
between the website they thot they were talking to and URLs (and then SSL 
authenticated
the relationship between those known URLs and the website). For the most part 
those
assumptions are no longer valid ... which then breaks the security model and 
all bets
are off. With the potential attacker frequently providing both the URL and the 
website,
then the only thing SSL is providing is authenticating the website that the attacker 
claims to be (via the URL) is the website that they are (breaking original basic
assumption about SSL). This totally invalidates the assumption that SSL is proving 
that the website that the user *thot* they were talking to (via directly entering 
the URL) was, in fact, the website that they were talking to (aka the user has
no idea what website they are talking to ... because they no longer have the 
knowledge
about the relationship between websites they think they are talking to and the 
URLs
for those websites).

The (*URL*) name to key mapping isn't the problem ... that is the mechanics that 
SSL provided. The problem was that SSL security had implicit assumption that the
user knew the mapping between the website they think they talk to and the URL 
for
that website. In the current environment, that assumption is no longer valid,

So the basic, most common PKI infrastructures provide a trusted public key 
repository
(typically manufactured into browsers before they ship). Users are 
indoctrinated that
they can trust those public keys ... for the purposes of digitally signing 
digital
certificates. These digital certificates provide the binding between URL 
(actually
the domain names part of URL) and website public keys. It is imperative that the
user (knowledge) then provide the binding the website they think they are 
talking
to and the URL. That is the part that is missing in today's environment (and 
what
large numbers of attackers can leverage to slip thru the "cracks").

The missing piece is trusted binding between who the user's think they are 
talking
to and the URL (or at least domain name). This could be accomplished by a 
separate trusted repository ... names that the end-user relates to and trusted 
binding between those names
and URLs. Attacker provided URLs that are clicked on ... then can be 
cross-checked
with things in that new trusted table (analogous to the way that the browser 
table
of certification authority public keys are trusted).

Then the issue is that if there is a trusted table mapping names to URLs (or at 
least
domain names) ... and a separate table of trusted public keys ... the whole 
thing
could be collapsed into a single table ... totally eliminating the level of
indirection provided by (redundant and superfluous) PKI and certification authorities 
... just add the public key to the trusted table of names & domain names (aka URLs).

The issue isn't so much that SSL is broken ... it is the implicit dependency on
users knowing the relationship between the website they think they were talking
to and the URL for those websites. Creating a user trusted table of website/urls
(analogous to the browser trusted table of certification authority public keys),
can make PKIs and certification authorities redundant and superfluous ... since
in whatever trusted process is used to maintain the trusted table of 
website/urls
... can also directly include the public key for those website/urls.

this is similar, but different to some of the domain name infrastructure 
proposals that
would allow real-time retrieval of on-file, domain name public keys (also making
PKIs and certification authorities redundant and superfluous). Some past posts
discussing catch-22 for PKI infrastructures with real-time domain name 
infrastructure
public keys
http://www.garlic.com/~lynn/subpubkey.html#catch22

other posts about certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

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