|
Re: [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt
2016-01-11 10:08:09
On 1/10/16 11:29 PM, John C Klensin wrote:
[points out that envelope information isn't all the metadata, and this
would only protect envelope information]
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.
I winced a bit as I typed the word metadata, because of course the fact
of a connection between two MTAs is metadata in itself. I'll resolve to
be more precise in my terminology. But SMTP TLS protects about more than
the envelope information: the message header, including header fields
like Subject, To, and Cc, are sent in the clear for end-to-end encrypted
email, and this reveals a lot more information to an eavesdropper.
(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
extensions.
Doing something other than drop the bounce needs to be considered very
carefully because it has the potential to be exploited. I'm particularly
concerned about the trusted third-party fallback: granted that this
creates another reason to bounce a message, but if bounces are that
critical, wouldn't someone have already proposed fallback bounce mechanism?
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.
This is just semantics; "make life miserable for casual eavesdropping"
strikes me as an answer to "why".
(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.
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.
Looks like I have a bit of homework to do. I can definitely see how
REQUIRETLS would create a community of a subset of MTAs that can
communicate when that option is requested, but I don't see any situation
where a non-REQUIRETLS capable sender would not be able to send to the
REQUIRETLS community.
(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
generally.
Maybe an IMAP/POP document will come along eventually, but in any case
it's important to acknowledge the need for secure delivery.
-Jim
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
|
|