[Top] [All Lists]

Re: [ietf-smtp] Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd)

2013-10-17 15:16:13

[sorry if this is a resend]

On Wed, Oct 16, 2013 at 11:29 AM, Martijn Grooten <
ietf-smtp(_at_)lapsedordinary(_dot_)net> wrote:

On Wed, 16 Oct 2013, Wei Chuang wrote:

This argument ignores the argument that there are measures to make the
life of the eavesdropper much more difficult.  I would argue that
instead of absolutist stance, that if one can make it difficult enough,
then eavesdroppers/adversary will 1) find their costs go up and number
of campaigns they can afford will drop, and/or 2) have to find somewhere
else to attack.

Hi Wei,

thanks for your comments.

I think we all agree that making an attacker's life harder is a good idea.
Which is why we've all said that using TLS is a rather good idea. But your
proposal has the potential (or, in my view, likely) side-effect of breaking
email delivery,

The other side of the coin is that this is a feedback signal for the sender
as well as the destination mail provider.  Also I would just reiterate the
point (which really is the motivation for this I-D) that the ecosystem is
in a partially state with only a few providers with SMTP STARTTLS.
 Initially this feature would be used likely by a small set of users that
need this say for business requirements, but can scale up as the ecosystem
adopts SMTP STARTTLS.  Also this proposal provides a way for a SMTP server
to display the providers capabilities, so users won't have to randomly send
messages that will break during delivery.

while suggesting senders have more control over the security of the
message in transit than they really have.

Also, seeing as the text refers to "recent news": it's not my impression
that the NSA would give up if only we made life too expensive for them.

 I would also differ in that the email would not be delivered.  If there
is a security bounce, the user will be informed that their requested
security level was not met.  It is up to them to figure out another
secure delivery method and/or communication method.  But at least unlike
the current model, the user has the choice.

Only as far as they can trust whichever entity deals with the message when
it's in transit to speak the truth.

(I also think thay making people try something in a secure way and then
giving them the option to try it in an insecure way is bad for security in
general. Even if it kind of makes sense here - after all, there isn't much
guaranteed security in the first place.)

      Here you rightly mention the limitations of SMTP TLS, even
compared with HTTPS. I don't think this is addressed adequately enough
further in the text.

If you could expand on this, I would appreciate it.  The body of the
document was already getting long IMO but I would be happy the address

The text says

    "Moreover SMTP TLS is more susceptible to active attack such as Man-
   in-the-Middle (MitM) than web client security.  Attacks such as
   certificate forgery or TLS downgrade have been mitigated with
   certificate pinning [2] and HSTS [RFC6797].  No such mechanism exists
   today with SMTP TLS."

which I read as an argument why TLS isn't all that fantastic when used for
SMTP. Then the text goes on to explain how we should use TLS for email. I
think it should be clear about what threats this protects against and what
it doesn't.

I brought up eavesdropping and MitM as threats to be concerned about and
addressed them in the proposal.  The baseline does not do a good job
against those attacks but the TLS tiers mitigate them as noted in the

      Do you want the signing domain to bear some relation to the
5321.From or 5322.From addresses, the HELO domain, the PTR of the
sending IP, or does it suffice for the email to have been DKIM signed?

Request to expand on this...  i.e. which is preferred and why?

I'm not really sure. I think DKIM-signing emails is a good idea in
general, and I'm pretty agnostic as to who signs which emails - as long as
it happens in a somewhat consistent way.

In this case I'm just not sure - your scheme doesn't look into the
question of authenticating the sender. If it did, then having it signed by
the domain in the 5322.From address could provide some (extra)
authentication - but I'm not sure if I would want to make that a

This is the justification for using tiers, to make it easier to adjust
as TLS best practices changes.  The reason for specifying TLS minimum
parameters, is that the weak TLS configurations is worrisome.  Key size
is one example of this.  I understand that RC4 might be controversial.

My point is that we all agree that weak TLS isn't a good thing. I just
don't think that hardcoding what is good security (e.g. ECC with key size

= 250) is a good idea, as new discoveries might change our understanding

of what good key sizes are. I'd rather not see the IETF have to go through
the process of updating lots of RFCs, just because ECC turns out to be
easier to break than previously assumed.

(Disclaimer: I haven't read a lot of RFCs that deal with cryptography.
Perhaps they do have minimum key lengths hardcoded into them - in which
case probably for good reasons.)

I think there was a suggestion to break out the TLS spec from this proposal
(if it gets to around to being updated)- it could exist as a best practices

      I do like the idea of using several tiers - but also wonder what the
implications will be when you demand tier 2 or higher and I can only
provide tier 1 security. Won't this just mean emails get bounced all over
the Internet?

It will mean that there will be more bounced mail.  But I would argue
that this is what the user desired as described above.

Assuming they understand what they do. I find it hard enough it imagine
cases where someone would be happy for an email to be sent through the
store-and-forward principle of SMTP, but would rather have it bounce than
be sent over unencrypted connections. I find it even harder to imagine a
case where someone is still OK with that store-and-forward principle, but
doesn't want the email to be sent if not very strong encryption can be used
in transit.

I argue that yes corporate and power users would find this useful
initially, and as the ecosystem moves to securing mail delivery, this could
be turned on by default for everyone else.  There would also have to be
education of users as well.

I don't want to be one of these people who goes on about how users can't
be educated, but let's it's not going to be easy. And some of the things
you will tell people seem to contradict other things we, as the security
community, will continue to tell people.

(I do think that there may be a point where 95% of email traffic,
including IMAP and POP3, is sent over TLS. By that time, we may want to
look into making MTAs refuse to send email to the other 5%. But we're
nowhere near there yet.)

I think this is the chief criticism, and one that was argued by colleagues
here at Google as well.

thanks for the comments,



ietf-smtp mailing list

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>