ned(_dot_)freed(_at_)mrochek(_dot_)com writes:
In any case, there are a bunch of reasons why TLS is effectively a nonstarter
for this. The following list is likely nowhere near complete:
Let's put this in perspective: a non-starter vs. an unstarted.
(1) More than one SMTP hop may actually be involved in getting from one
domain to another, or more to the point, from the system within one
domain that signs to the system in the other domain that verifies.
TLS can only cover one hop, and in so doing limits deployment
flexibility considerably. (There's a lot of room between end to end
protection and hop by hop protection - you make it sound like
there's none.)
But if all you want to know the identity across the trust
boundary of, say, a domain it doesn't seem very unreasonable
to require placement TLS-capable MTA's at those
boundaries. It seems to me that if you really want this
identity, that your flexibility is just *nice*, not a
requirement. Best vs. Good Enough, after all.
(2) The negotiated nature of TLS requires that the various cryptographic
operations be performed while the connection is open. The ability to
perform both signature and verification operations offline is very
important.
Why? MASS is not intended for long term verification in the
first place. Nor is it likely to be useful for many MUA's
like Outlook, Lotus and their ilk because they destroy the
body and headers.
(3) TLS increases the number of round trips required to transfer a message
considerably. This is a serious issue in some cases.
Vs... getting to make an accreditation check to stop it
cold. TANSTAAFL. Best vs. Good Enough.
(4) Sadly, initial deployment of TLS support in SMTP was botched in
a very serious way: A major vendor implementation decided to base
their test as to whether or not to offer the STARTTLS keyword in
response to EHLO on a check to see if certain cryptographic libraries
were present on the system. They didn't bother to check to see if
an appropriate key was present and valid. The result has been that
lots of servers offer the STARTTLS extension but when you try and
use it the negotiation fails, leaving the connection in an unusable
state. This effectively killed opportunistic use of TLS, and remains
a significant impediment to other uses of TLS today.
If you believe that any of this stuff is going anywhere at
all, there are going to be some pretty significant changes
to the infrastructure, including getting vendors to fix
broken behavior. I think this is true whether you believe in
your hopwise view of MASS or my more e2e view. So the easy
answer is to get those vendors to do the right thing.
(5) Existing TLS deployment for SMTP is oriented around using server
keys to provide confidentiality services. It isn't clear if the
necessary support is in place for client keying of the sort you'd
need for this application.
If what you're really after is just site-site accreditation,
is that a "nice to have" or a "must have"? Seems like
another good candidate for best enemizing good.
If people really think
that site-site crypto which ignores end to end assertions
are useless, why aren't they evangelizing the virtues of TLS
which is probably supported on the vast majority of MTA's
*now*? Why are you the enemy of the "Good enough"?
First, what makes you think this hasn't happened? The fact of the matter is
that the use of TLS between domains _was_ evangelized right after TLS support
in SMTP started appearing in products.
Now, this was long before spam had become the serious problem it is now, so
the
goal then was to limit the ability of attackers to eavesdrop on SMTP
connections, not to provide some form of client authentication.
However, to the extent that the bunch of people (and there really were a
bunch
of them) who called for this were successful in getting sites to try it,
those
sites ran smack dab into (4).
The world has changed, and the stakes have certainly
changed. That why we have any chance of making *any*
changes: MASS would have fallen just as flat as when
STARTTLS was being let loose.
FWIW, I'm not hostile to the general concept of evangelizing
TLS for the general good. MASS solves a different and
important problem, IMO. There already exists a solution for
the problem that you're trying to solve, even if it needs
some rust knocked off of it. In fact, I've always thought
that using TLS would be far better than SPF/CSV since IP
identies generally suck.
Mike