On Wed, Oct 16, 2013 at 12:38 PM, John C Klensin <john+smtp(_at_)jck(_dot_)com>
--On Wednesday, October 16, 2013 11:17 -0700 Wei Chuang
Do you mean TLS downgrade, poor ciphers or stealing certs?
or do you mean employing some sort of backdoor? The former
two issues are dealt with in the proposal where TLS is
specified and checked. As for detecting and mitigating bad
certs, I believe this is in discussion by the IETF. A future
TLS tier 3 could be specified as best practices for cert
protection is developed. (We think this will be certificate
transparency, which is mentioned in the proposal, but is left
open as to be determined by the community)
I meant stolen certs, backdoors, or direct compromises of a mail
store or mail queue in which the messages may be sitting around
in the clear before being relayed or delivered. See below.
Agreed that this proposal does nothing for subverted MTAs.
One argument though is that likely this is not at all common,
and for the vast majority of email, not going to be an issue.
Actually, I suggest that it has historically been a lot more
common than subverted links, especially subverted backbone
links. Remember that both of the following are instances of a
subverted MTA (or mail store) as far as privacy of the messages
(1) Some governmental agency or similar body comes along
with adequate documentation, claimed authority, and/or
threats and says "please dump all messages your receive
and give them to us", "please dump all messages sent to
or from Elmer Fudd between now and the end of the week",
or anything in between.
(2) Some entity associated with the one that operates
the mail service scans the contents of all messages
sent, received, or stored there for purposes of service
improvement, user interest detection for advertising
purposes, or data mining and database construction.
Note that neither of those is a technical attack and that it
makes no difference to either whether the actions are legal or
not; allowed by policies to which the user has agreed or not.
The only issue is that the messages are sitting around in the
clear and available to anyone who, with permission or not, gets
access to and control over the MTA or mail store.
Agreed that this proposal does nothing to protect against this type of
threat. If the proposal gets around to being rewritten, I'll further
clarify this point.
thanks for the clarification,
Only solution here is I think you're implying is end-to-end
email encryption. I should mention that the proposal do
nothing to preclude it, and I would argue its complementary as
TLS protects metadata during delivery.
It protects a small amount of metadata. How much depends on
circumstances and, in particular, whether the machines involved
support enough users each to make speculation about who is
sending messages to whom useless.
First, yes, end-to-end encryption (really content encryption) is
the only solution if one doesn't trust the relay server or mail
store operators, the security of those servers, or the
environment in which they operate. It also has the advantage of
not being subject to the complex handoff and "get partway and
bounce" issues that you and others have commented on. It think
that is part of what Martjin, myself, and others, said. We all
know the problems with it even though we regularly tend to
forget that (end to end) secure messages can be exchanged among
cooperating parties by the use of old-fashioned symmetric
cryptography with shared secrets and even one-time pads (and
maybe, as we try to figure out how to make public key methods
work, we should have an Internet standards for that).
As I said earlier, I don't want to discourage your efforts in
any way. I think you just need to be very clear about the
threat model and what problems are actually being solved.
That is certainly not an argument against doing TLS or
otherwise protecting the links because there is clearly a
there. Whether it is worth going to extra trouble (and
not having messages delivered that are otherwise ok) to
promise that such methods will be used is a more complex
question that is, indeed, closely related to what the users
will perceive is being promised.
I would differ here. As pointed out in the proposal's
motivation, leaving mail delivery as clear text mail makes
mail delivery the weakest link for many mail providers. It
invites adversaries with lots of resources to attack this
point as other interfaces become much more hardened.
With no disrespect, a matter of opinion. Or perhaps it is a
matter of how one thinks about the threat model. Hardening a
server technically is of little use if someone from the
government, police, etc., can show up with legal papers and/or
threats and obtain content that way.
ietf-smtp mailing list