On Fri July 1 2005 08:21, Keith Moore wrote:
not sure what you mean by that. with TLS the server is authenticated
via the server certificate. a hijacker doesn't have access to the
session key and can't set its own session key without causing the server
signature verification to fail.
TLS seems to work fine through proxies; what prevents the MitM
from setting up a proxy? (If OPES bears fruit, hijackers may
feast)
Also bear in mind that there are different levels of TLS
authentication: server, client, and both. HTTP typically
authenticates the server to the client; SMTP AUTH typically
authenticates the client to the server. In the former (HTTP)
case, if the server wishes to authenticate the user, some
additional method (e.g. login/password) is used. For SMTP
AUTH, well the client just can't tell for sure if it's talking
to the real McCoy.
of course, there are clients that don't check server certificates,
There's a problem with certificates (also other schemes); they rely
on some sort of trust relationship. For certificates in particular,
there's a self-signed certificate at the end of the chain (or the
moral equivalent).
Why should I trust a certificate from some company in South Africa
that I've never dealt with? Worse, what about this other certificate --
isn't that the company that screwed up DNS for everybody with bogus
wildcards -- "I trust [them] as far as I can comfortably spit out
a rat"?
In practice -- because mere mortals don't know enough about every
individual and organization that might present a certificate or
other token -- it tends to become just another "click on yes"
annoyance. Maybe once in awhile (say, isn't that the company
that screwed up DNS...) it's "click on no", but then things don't
work so it's quickly back to "click on yes".
This is a particularly problematic issue for mail as distinct
from http. The fundamental premise of email is that anybody can
send to anybody else -- how is a user supposed to keep track of
chains of certificates for billions of potential correspondents
and figure out whether or not to accept one from a stranger (who
might be a potential customer/employer/benefactor, or might be a
spammer)?
How would this work for the typical Internet user -- whose mail
is received by an ISP into a POP mailbox, which is then downloaded
by the user -- when mail is received by the ISP, the user may be
off-line (and unable to respond to certificates); POP has no
per-message certificate exchange mechanism?
there are multiple ways to solve the problem. one is that if a user
provides a certificate to the MSA that says "I have permission to use
this set of addresses in SMTP MAIL FROM" then the MSA permits such use.
Do self-signed certificates count? What about ones signed by
entities know to have caused damage to the email infrastructure?
Who decides? On what basis? How would this work with your
scenario of having to use a strange MSA? What if no MSA is
available (some ISPs support only an MTA for sending; in other
cases it may be necessary to connect directly to a recipient's
MX MTA to work around DNS or other network problems)? Who
decides when an SMTP receiver is an MSA or MTA? How can the
client tell the difference?
another way (which only works for individual addresses) is that you get
the MON to send a single message to a MAIL FROM address, the message
contains a cookie, you reply to the message, now the MON knows you can
read mail sent to that address and so are presumably able to use it.
A widely-respected (if anything, not respected widely enough) rule
is "never respond to spam". How is a typical user (ESR's Aunt Tillie,
for example) supposed to be able to distinguish such an unsolicited
message from that sent by a spammer who is simply trying to confirm
mailboxes in preparation for a new "Two Hundred Million Verified Email
Addresses" CD-ROM?
another is that the MSA makes the mail traceable in some way other than
MAIL FROM to a user who can be held accountable for his actions - then
if the user sends out mail that abuses MAIL FROM then he gets billed for it.
Billed by whom? Who collects the money? Under which legal jurisdiction?
Who gets the money? The joe-job victim? Some random ISP? Some rich
lawyer? Some government bureaucrat? What prevents forgery of that
mechanism (i.e. how do you prevent a joe-job victim from being erroneously
billed)?