[Top] [All Lists]

Re: [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt

2016-01-10 19:49:31

--On Sunday, January 10, 2016 14:27 -0800 Jim Fenton
<fenton(_at_)bluepopcorn(_dot_)net> wrote:

Below is the announcement of a draft I just submitted that may
be of interest to this list. The approach here is
complementary to the other proposals I have seen along these
lines (e.g., smtp-sts).

Thoughts, reviews, etc. welcomed.


I have skimmed through this.  A few observations, many of which
apply to most or all of the "other proposals along these lines"
that you mention.

(1) I appreciate the last paragraph of your Security
Considerations section.  We need to keep in mind that there are
multiple threat models to mail privacy/confidentiality and that,
if mail servers can be compromised, encryption in transit may
not add much value (or may add a false sense of security).   As
you point out,  certain DNS compromises may not be much better.

(2) The issue of encrypting information on the reverse path (not
just error messages, but delivery and non-delivery notifications
of all types) is a difficult one.  Although it is likely in the
common cases, there is no way to guarantee from the presence of
encryption capability on the forward path that encryption on the
reverse path will be supported (and properly configured, etc.)
In particular, if the preferred MX-based route between A and D
is A->B->C->D, nothing at all guarantees that the route from D
to A will go through B and C.   In a way, part of this is not
new: A doesn't have to operate an SMTP-receiver in order to send
messages to D, but it certainly needs to have one to receive
error messages (as distinct from SMTP-time rejections).

Even if you decide against it, I think you need to consider that
situation carefully and, in particular, consider whether
parameters that allow the message originator to specify levels
of preference about what should happen if notification messages
cannot be encrypted.

(3) The EAI WG struggled for a long time with the relationship
between a requirement for certain SMTP options (i.e., if the
option is requested (or required) by the client but the server
will not accept it, the message content must not be sent) and
our MX structure.  For example, suppose (to generalize, the XYY
option is at issue and required.   Suppose we have IN MX 10   A.EXAMPLE.COM.
                IN MX 10   B.EXAMPLE.COM.

A supports XYZ and B does not. 

Now, suppose wants to send a message to
user(_at_)example(_dot_)com and wants to send it with transport encryption.
RFC 5321 is fairly clear that it is to pick arbitrarily between
A and B.  If it happens to select A, then all is well.   But, if
it selects B and successfully opens the SMTP connection, B will
not advertise REQUIRETLS and your spec, as I read it, then
requires that D stop, close the session, and tell the originator
that delivery was not possible.  More complex versions of that
scenario with, e.g., choices at different preferences or names
with multiple addresses but different services supported at each
address, can create even more interesting solutions, different
paths, etc.

In the EAI case, it turns out that there is no plausible
"downgrade" path corresponding to "give up and send clear text"
in historic STARTTLS so "required extension" is the only game in
town and messages either go through or they don't.   However,
the strongest critique of EAI -- IMO an entirely valid one at
least until the protocol extensions are widely deployed -- is
that it basically divides the email world into two communities
who can't talk with each other.  You risk the same type of
issues here.    I would recommend (and, again, this applies to
this family of proposals, not just yours) careful study of the
EAI specs to help understand the issues and tradeoffs.

(4) Similarly, you can say that, if a message arrives with
REQUIRETLS, IMAP and POP clients and servers use "authenticated,
encrypted channels".  However, in actual systems as deployed,
carrying the REQUIRETLS information along the SMTP path and
acting on it may be (and typically is) far more simple than
doing whatever is necessary to carry that information through
the mail store and make it available to control the behavior of
the server side of various split-UAs.  Equally important, it is,
in the general case, impossible for a server to know what
selection of delivery-side client (and their capabilities) are
available to a given user and the idea of having some messages
in the message store for a particular user that can be retrieved
and read by that user via some clients but not others is a
troubling one.   It may, in some cases, be even more troubling
for transport security than it is for the EAI cases.   Again, a
study of the EAI specs and their history may prove helpful.

In addition, to a much greater degree with IMAP and POP than
with SMTP transport, if, e.g., an IMAP server can determine the
message content has already been encrypted by some end-t0-end
mechanism, it may be reasonable for it to care a great deal less
about an encrypted channel than it might otherwise.  Such a
server might even encrypt the message using end-to-end
techniques before delivering it (just as some IMAP servers are
set up to hold sufficient private keys and decrypt such messages
at the time they are requested by the client.   So I think that
section may need a bit more thought and explanation.


ietf-smtp mailing list