ietf-smtp
[Top] [All Lists]

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

2016-01-10 21:38:10
On 01/10/2016 05:49 PM, John C Klensin wrote:

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

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.

Thanks. The flip side of this is that end-to-end encryption doesn't
protect the metadata. We would still want to protect it from being
visible on the wire.


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

This is a good topic for further discussion. One option might be to send
a bounce that contains very little information about the original
message other than the message ID and the envelope-from address. I want
to make sure that we don't expose the metadata any more than absolutely
necessary since protecting it is part of the value proposition of SMTP TLS.

I'm a little cautious about having another option for bounce treatment.
Under what circumstances would you send a message with REQUIRETLS and
not care about the security of what's in the bounce message?


(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 

   example.com. IN MX 10   A.EXAMPLE.COM.
                IN MX 10   B.EXAMPLE.COM.

A supports XYZ and B does not. 

Now, suppose D.example.net 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.

More explicit treatment of multiple MX situations like this is
definitely needed.

I haven't been following the EAI work at all; if you have more specific
pointers to the split-communities problem you describe, that would be
very helpful.


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

I am trying to constrain this mechanism to the SMTP protocol as much as
possible. The intent in section 3.4 is that MDAs that support REQUIRETLS
should deliver all their mail, not just the REQUIRETLS-tagged messages,
via encrypted channels. It would be kind of a mess for IMAP to only
deliver a subset of the messages in the mailbox compared with IMAPS.
Probably even worse for POP. Delivery over encrypted channels is the
Right Thing To Do anyway.

Thanks for your comments.

-Jim



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

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