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, 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
this.
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.
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
requirement.
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 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.)
Martijn.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp