ietf-mailsig
[Top] [All Lists]

Re: Want a BoF at IETF 62?

2005-01-07 10:00:38

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.

I'm afraid I give a lot more weight to past failed attempts to do things than
you do.

 > (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.

It is nowhere near good enough, I'm afraid, given how many large sites - sites
you really want to have adopt this - are set up.

I happen to think some of these designs are seriously busted, but my
opinion isn't particularly relevant here.

 > (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.

Again, it clashes badly with some site designs.

 > (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.

This one is much less of an issue, but it does add to the pile. And when
the pile gets high enough... People walk away.

 > (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.

But the goal needs to be to minimize the need for such changes.

 > (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.

I fail to see how you can possibly get any sort of accreditation out 
of TLS without having some sort of client key in place.

 > > 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.

You'd think so, wouldn't you? But here you are, apparently arguing that it is
essential to keep the end to end stuff in MASS, unwilling to compromise in
order to get enough consensus to even form a working group, let alone enough to
come up with a concrete proposal for a deployable service.

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.

Then by all means write up a draft describing it, get it adopted, and prove me
wrong. I personally have no time to spend on things which are, in my judgment,
nowhere near good enough in terms of deployability.

In any case, it is now clear that this discussion is going nowhere, so this
will be my last posting on this general topic.

                                Ned


<Prev in Thread] Current Thread [Next in Thread>