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 [EMAIL PROTECTED]