Absolutely true. If the "only" effect of a MITM is loss of privacy, then that is certainly a
lower-priority item to fix than some quick cash scheme. So the "threat model" needs to clearly
define who the bad guys are, and what their motivations are. But then again, if I am the victim of
a MITM attack, even if the bad guy did not financially gain directly from the attack (as in, getting
my money or something for free), I would consider "loss of privacy" a significant thing. What if an
attacker were paid by someone (indirect financial gain) to ruin me by buying a bunch of stock on
margin? Maybe not the best example, but you get the idea. It is not an attack that affects
millions of people, but to the person involved, it is pretty serious. Shouldn't the "server" in
this case help mitigate this type of attack?
ok, the original SSL domain name certificate for what became electronic commerce was
1) am I really talking to the server that I think I'm talking to 2) encrypted session.
so the attack in #1 was plausably some impersonation ... either MITM or straight impersonation. The issue was that there was a perceived vulnerability in the domain name infrastructure that somebody could contaminate the domain name look up and get the ip-address for the client redirected to the impersonater.
The SSL domain name certificates carry the original domain name .... the client validates the domain name certificate with one of the public keys in the browser CA table ... and then validates that the server that it is communicating with can sign/encrypt something with the private key that corresponds to the public key carried in the certificate ... and then the client compares the domain name in the certificate with the URL that the browser used. In theory, if all of that works .... then it is highly unlikely that the client is talking to the wrong ip-address (since it should be the ip-address of the server that corresponds to the server).
So what are the subsequent problems:
1) the original idea was that the whole shopping experience was protected by the SSL domain name certificate .... preventing MITM & impersonation attacks. However, it was found that SSL overhead was way to expensive and so the servers dropped back to just using it for encryption of the shopping experience. This means that the client ... does all their shopping ... with the real server or the imposter ... and then clicks on a button to check out that drops the client into SSL for the credit card number. The problem is that if it is an imposter ... the button likely carries a URL for which the imposter has a valid certificate for.
or
2) the original concern was possible ip-address hijacking in the domain name infrastructure .... so the correct domain name maps to the wrong ip address .... and the client goes to an imposter (whether or not the imposter needs to do an actual MITM or not). The problem is that when somebody approaches a CA for a certificate .... the CA has to contact the domain name system as to the true owner of the domain name. It turns out that integrity issues in the domain name infrastructure not only can result in ip-address take-over .... but also domain name take-over. The imposter exploits integrity flaws in the domain name infrastructure and does a domain name take-over .... approaches a CA for a SSL domain name certificate ... and the CA issues it ... because the domain name infrastructure claims it is the true owner.
So somewhat from the CA industry ... there is a proposal that people register a public key in the domain name database when they obtain a domain name. After that ... all communication is digitally signed and validated with the database entry public key (notice this is certificate-less). This has the attribute of improving the integrity of the domain name infrastructure ... so the CA industry can trust the domain name infrastructure integrity so the rest of the world can trust the SSL comain name certificates?
This has the opportunity for simplifying the SSL domain name certificate requesting process. The entity requesting the SSL domain name certificate .... digitally signs the request (certificate-less of course). The CA validates the SSL domain name certificate request by retrieving the valid owner's public key from the domain name infrastructure database to authenticate the request. This is a lot more efficient and has less vulnerabilities than the current infrastructure.
The current infrastructure has some identification of the domain name owner recorded in the domain name infrastructure database. When an entity requests a SSL domain name certificate ... they provide additional identification to the CA. The CA now has to retrieve the information from the domain name infrastructure database and map it to some real world identification. They then have to take the requester's information and also map it to some real world identification. They then have to try and see if the two real word identifications match. The recording of the public key for certificate-less authentication ... not only improves the integrity of the domain name infrastructure (so that it can be better trusted by the CA industry) .... but it can also convert a very error prone identification process for certificates into a simple authentication process.
So now we have the catch-22 clinker for the CA industry (since they are somewhat sponsoring this whole idea)
1) if the certificate-less public key process improves the integrity of the domain name infrastructure, then one can claim that the integrity concerns about the domain name infrastructure are lessoned and therefor the perceived requirement for SSL domain name certificates is lessoned
2) if the CA industry can use the registered public key for certificate-less authentication regarding domain name related operations ... then presumably the rest of the world can also ... which would further eliminate justifications for SSL domain name certificates (i don't need to get the server's public key from a certificate .... I could get it from a dynamic, trusted, information distribution utility ... the domain name infrastructure).
as before ... misc SSL domain name certificate related posts: http://www.garlic.com/~lynn/subpubkey.html#sslcerts
the following also have some references to domain name hijacking events (as opposed to ip-address hijacking):
http://www.garlic.com/~lynn/subpubkey.html#fraud
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
