ned(_dot_)freed(_at_)mrochek(_dot_)com writes:
> > A MASS protocol which fails verification
> > some large percentage of the time, IMO, is a failed
> > protocol.
>
> That's exactly the point, and that's why mandating suport of end to
> end operation is a mistake.
Then I'll ask for about the 5th time: why is TLS between
domains insufficient for that task?
AFAIK this is the first time you've ever asked me this.
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:
(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.)
(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.
(3) TLS increases the number of round trips required to transfer a message
considerably. This is a serious issue in some cases.
(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.
(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 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). Users really don't want to hear their admins yack
about how useful protection against eavesdropping is when bunches of their mail
is timing out and bouncing. Other sites experienced performance problems along
due to issues (2) and (3). The result is that sites quickly dropped their
attempts to use TLS this way and the effort to deploy an opportunistic
encryption service failed miserably.
I can only speak for myself here, but I have on more than one occasion given
serious thought to proposing a TLS-based solution, issues (1) and (2)
notwithstanding. But every time I consider it I remember the previous attempt
to deploy TLS this way and what happens, and I also remember that the old adage
"once burned, twice shy" applies in spades to sysadmins.
Ned