X.509 / PKI, PGP, and IBE Secure Email Technologies

[Anne & Lynn Wheeler]

Ben Laurie wrote:
> Eh? It surely does stop MitM attacks - the problem is that there's
> little value in doing so for various reasons, such as no strong binding
> between domain name and owner, UI that doesn't make it clear which
> domain you are going to, or homograph attacks.

part II;

i've repeatedly asserted that the fundamental, underlying certificate
business practices is to address the first time communication between
complete strangers ... analogous to the letters of credit/introduction
from the sailing ship days.

so the original SSL design point was to cross-check the domain name from
the URL typed in by the client to the certificate supplied by the
server. that basic premise is underminned when the server supplies the
URL and the certificate.

so you are left with placing the burdon on the user to cross-check the
URL displayed with the URL they think they are going to. it is simple
human dynamics ... after the first several thousand displayed URLs ...
they are going to ignore the process.

this is somewhat akin to the share-secret passwords ... that the
security experts define that the user has to have hard-to-guess,
impossible-to-remember passwords that change every 30 days, can never be
written down and every new password has to be unique ... as well as
unique across all security domains. the problem is that the number of
unique security domains that a person deals with has grown from 1-2 (I
had my first logon password in the 60s followed with the addition of an
ATM pin in the late 70s) to scores ... there is no practical possibility
that all such requirements can be satisified. misc. past collected posts
on shared-secret
http://www.garlic.com/~lynn/subpubkey.html#secrets

the underlying infrastructure further complicated the whole process when
a large percentage of the merchants outsourced the payment process to
3rd party ... where the click button supplied a URL of the 3rd party
payment processor that had absolutely no relationship to the merchant
site the client had been shopping at. this not only creates the
situation where

1) any initial connection to a merchant site where the user might
possibly have typed in the URL (or controls the URL generation via other
mechanisms) is not checked ... and any actual checking for things like
MITM-attacks doesn't occur until there is a URL provided by a
potentially suspect site.

but also

2) conditions the user as normal process that the pay/checkout button
may have a complete different domain name URL than the domain name of
the shopping site.

so, pretty well documented human factors ... especially related to the
design of security systems ... is that you don't tie humans making
determination about soem security issue to something that repeatedly
happens thousands and thousands of times. there are some guards that
have to check badges against faces ... but they tend to have intensive
training AND organizations that have high volume have gone to guards
doing it only short periods and rotating ... and/or the guards are
looking for a very simple repeating pattern and are trained to look for
missing pattern). having the human have to repeatedly check a (URL)
field that changes several thousand times a day against something they
are suppose to expect ... is pretty quickly a useless security design.

a more sensible human factors design ... is to remember whether a person
has checked out first time communication with a stranger ... the real
first time, have the person do something additional ... and from then on
remember that checking. in that respect ... creating a dependency on the
user to repeatedly check a field that changes possibly thousands of
times per day is extremely poor human factors security design.

now, the other part of my constant theme about certificates having
design point of first time communication between complete strangers ...
involves the additional constraing that the relying party has no other
recourse to obtain information about the other party. if you go to
paradigm where the relying party has facilities to remember first time
checking ... then the appended certificate on the communication is
actually only useful for the real first-time-communication (since by
definition the relying party has facilities to remember previous
checking ... like saving away the other parties publickey in a trusted
public key repository).

another part is that if you have the relying party do some additional
checking on the real first time interaction (rather than expecting the
user to do increasingly trivial checking on each new URL) ... and the
user is really online ... then that first time checking can involve
real-time check of online resources .... again invalidating more of the
underlying design point of appending a certificates on every
communciation for benefit of relying parties who have no other recourse
for determining information about complete stranger in first time
communication.

there is something of a dichotomy here ... where there is a somewhat
justification for certificates, based on the explanation that it could
be too onerous for end-users having to do anything unusual for
first-time communication with complete stranger (and therefor there is
no dependency on local repository for remembering such additional
checking and/or infrastructure that might be able to allow for the user
to do real-time, online checking) ... but at the same time there is
sometimes stated that there is a dependency on the user checking
thousands and thousands of changing URLs every day to make sure they are
what the user expected them to be (which is pretty much been a long
recognized poor security design point).

again, collected past posts on ssl certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

as to the other point about their being a week binding between URL
domain name and owner; there are recognized integrity weaknesses in the
domain name infrastructure (including the binding between the domain
name and the domain name owner), however as previously stated, the SSL
domain name certification authority certification process is dependent
on the integrity of that information (as the TRUST ROOT basis for
performing the certication, that in turn, is represented by a stale,
staic certiciate). i would claim, in the minds of end-users, there is an
icnreasingly growing weak binding between the parties that consumers
have to deal with on the internet and any domain name. furthermore
creating a security foundation based on end-users having to mentally
correlate URL domain names in a field (something that is constantly
changing thousands of times per day) with external entities is a long
recognized poor security design point.

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