Using crypto against Phishing, Spoofing and Spamming...

[Anne & Lynn Wheeler]

At 05:55 PM 7/17/2004, Eric Rescorla wrote:
>Now, my threat model mostly includes (1), does not really include
>(3), and I'm careful not to do things that leave me susceptible
>to (2), so SSL does in fact protect against the attacks in my
>threat model. I know a number of other people with similar threat
>models. Accordingly, I think the claim that "secure browsing
>is not secure" rather overstates the case.


there sort of two parts of SSL .... I believe the original justification 
was based on perceived integrity issues with the domain name infrastructure 
and various kinds of hijacking attacks. the client got back a certificate, 
verified the integrity of the certificate (from a table of certificate 
authority public keys), verified that it appeared to originate from the 
certificate owner and then compared the certificate domain name string with 
the domain name used in the URL. once that was done, there was key-exchange 
to protect the contents of the transmission.

the catch22 was that the domain name infrastructure is also the 
authoritative agency as to the owner of the domain name. the SSL domain 
name certification authorities have this horrendously, error prone and 
expensive problem of getting sufficient identification information from the 
certificate applicant and attempting to match it with the identification 
information carried by the domain name infrastructure as to the owner of 
the domain name.

so the first issue is that the integrity of the domain name infrastructure 
could be attacked with a domain name hijack ... then the attacker applies 
for a certificate .... and the identification provided the certification 
authority and the identification on file with the domain name 
infrastructure compare ... and the attacker gets a valid certificate.

so the certification authorities came up with a proposal to have domain 
name registers .... also supply a public key at the time of registration. 
then future communication with the domain name owner is digital signed ... 
which the domain name infrastructure can verify with the public key on 
file. this is a countermeasure against domain name hijacking (improving the 
integrity of the domain name infrastructure and rising the trust that 
certification authorities can place in the authoritative agency). the other 
issue is that the certification authorities can use the public key on file 
with the domain name infrastructure to turn an expensive, and error-prone 
identification process into a much simpler and KISS authentication process 
.... aka domain name certificate applicants digitally sign their requests 
... which are then verified with the public key on file at the domain name 
infrastructure.

the two issues then are that with increased domain name infrastructure 
trust ... 1) it should reduce the demand for domain name SSL certificates 
(motivated by integrity concerns about the domain name infrastructure) and 
2) it could eliminate the need for domain name SSL certificates .... since 
all clients could possibly also use the public keys on file with the domain 
name infrastructure (in lieu of needing to get public keys from certificates).

So now to the key-exchange issue protecting credit-card numbers from 
evesdropping and harvesting. The issue is that the crooks tend to go after 
the best fraud ROI (return on investment). The claim is that it is so much 
more profitable to harvest the merchant transaction file .... that until 
that barn door is closed .... the crooks have little incentive to go after 
credit card numbers by evesdropping packets in flight. There have been some 
assertions that there has been no known cases of picking up account numbers 
from packet evesdropping .... even where SSL or any other encryption is 
being used to protect data in-flight. Part of the issue is that 
evesdropping packets takes a lot more work ... and provides much less 
return than going after the merchant transaction file. Other scenarios have 
also been end-point attacks ... where password files are harvested and/or 
viruses are installed at end-points to harvest information .... as opposed 
to doing anything with data in-flight.

So, it could be claimed that there is some question about what is cause and 
what is effect i.e. are the end-point attacks because everything is 
encrypted .... or are the end-point attacks occurring because they are so 
much more profitable and easier. Given that there are significant amounts 
of non-encrypted traffic ... then the claim could be made that the crooks 
are getting so much more from end-point attacks ... and until that is 
addressed ... that attacks on data in flight is somewhat academic (since 
there is so little evidence about fraud happening from data in flight 
attacks). The other argument has traditional been that 90 percent of fraud 
has been insiders, typically also associated with various kinds of 
end-point attacks (rather than any kind of outsider attack on data in 
flight). There was some recent study that at least 77 percent of the 
identity theft has involved insiders. This would also indicate that the 
end-points are the primary points of attack .... and that data-in-flight 
attacks are of primarily of academic interests ... not particularly 
contributing to fraud, even when no encryption or protection is involved.

One might even assert that the attention paid to data-in-flight attacks is 
actually counterproductive ... distracting attention from the much more 
serious and significant end-point attack fraud .... which has always been 
the major problem.


--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

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