--On Sunday, January 10, 2016 19:38 -0800 Jim Fenton
On 01/10/2016 05:49 PM, John C Klensin wrote:
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.
Strictly speaking, hop-by-hop TLS doesn't protect "the metadata"
either. It just protects the SMTP envelope. The information
about what systems are connecting to what other systems is still
exposed to anyone with access to the relevant links (especially
links close to the originator) and, at least with current
technology, so are the DNS MX queries that precede the opening
of SMTP connections. For example, if an attacker can monitor
the links out of your submission server, log all SMTP queries
for MX records and all outgoing SMTP connections, and perform
some fairly simple statistical analysis over a period long
enough to work around DNS caching (or if the submission server
is not running a full-service resolver), it would have fairly
good information about which hosts and sending messages to which
other hosts. Following up on John Levine's comments, if,
instead of passively monitoring those links, it is in a position
to interfere with them by, e.g., mounting appropriate MITM
attacks, then, unless the client can verify the server with keys
and a very strong CA that can be trusted to verify identity
independent of domain ownership especially given the rotten
state of reverse mapping records (you do cover much of that, but
I'm not sure how plausible it is given practical experience),
the server can be spoofed by address diversion and all bets are
Of course, one gets significantly more protection from
information disclosure by transmitting from an origin at HotOl
to a destination at YaOgle, simply because of the amount of
traffic on those links, but one probably doesn't want to go
there, especially since transmission between two YaMail accounts
(or within any of the other relevant systems) doesn't involve
SMTP over the public Internet at all.
If that analysis is correct, then hop-by-hop TLS still provides
fairly good protection against casual eavesdropping, including
eavesdropping whose purpose is to see if anything interesting
turns up, but might be fairly weak against a focused and
determined attack by an attacker with significant resources.
And we should really, really, stop throwing the term "metadata"
around as if it described precise sets of information.
(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.
See above about "metadata", note that the observation of forward
and reverse path connections may provide a lot of information.
Or not, depending on the sets of systems involved. But yes, my
thought about those parameters, while vague, involved the sender
being able to express preferences for situations in which an
encrypted reverse path was not available including drop (the
only option in your current draft), cleartext, minimal response
(maybe more variations than the one you outline above), send to
trusted third party as a fallback, and maybe some others. An
originator who is smart and concerned enough to make rational
"I'd prefer that this message be bounced if it cannot go end to
end, encrypted during every hop" decisions out to be able to
sort those kinds of options out. Note that we've already got
options to request non-return of content in the notification
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?
I think the question is rather about how much I care and why I
care. If my main goal is to make life miserable for casual
eavesdropping (including raising the costs to anyone who is
doing it) rather than actually to protect specific message
content and/or I know something specific about the return path
(noting that the sender or something within the sender's
administrative domain is presumed to control those MX records
although not the MX records of the destination), I actually
might not care enough to want any non-delivery messages to be
anything but crystal clear. Similarly, if I've protected the
content end to end and in other ways, I might want the
incremental protection of envelope information by hop-by-hop
link encryption, but I might conceivably not care very much.
(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,
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
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.
Have a look at RFCs 6530-6532, noticing what they don't say as
much as what they do, and compare to 4952, 5504, 5825, 5336, and
5335 to get some sense of the earlier "try to fix it up on the
fly" techniques. The i18n issues are different from the ones
you face, but, as I suggested, the whole notion of "if this
extension isn't acceptable and excepted, forget sending" gets a
little tricky... something we were aware of when RFC 1425 was
coming together. One could imagine some interesting ways to
get around it, including reflecting the availability or absence
of certain SMTP extensions in the DNS, but that was before SRV
records and would have involved some of the same issues that led
to deprecating WKS.
(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.
It is a good thought, but maybe you should just take it out and
write an IMAP/POP specific document. To the extent to which
delivery over encrypted channels is the right thing to do
generally, it doesn't make any difference whether the message
arrived at the final delivery server via an encrypted link or
not, it is still the right thing to do. It is fairly easy to
make the case that is the right thing to do if the IMAP
client-server connection transits the public Internet and those
two systems are under separate administrative control. However,
if the client machine opens a well-designed secure tunnel to the
server or something with a local and protected connection to the
server and uses that tunnel for more than IMAP traffic (e.g,,
reaching web proxies, making DNS queries), then that tunnel will
hide everything, including whether IMAP is being used and
connections between the submission MUA and submission server.
Insisting that the IMAP connections then use IMAP-specific TLS
encryption is then properly described as "useless overhead".
Again, being clear about the threat models against which one is
protecting would be a big help, both in your document and more
ietf-smtp mailing list