Hi Martijn,
On Wed, Oct 16, 2013 at 3:04 AM, Martijn Grooten <
ietf-smtp(_at_)lapsedordinary(_dot_)net> wrote:
On Tue, 15 Oct 2013, Wei Chuang wrote:
Request for discussion (draft-wchuang-msmd) of a proposal to secure
mail from eavesdropping and MitM attacks. All comments welcome on this
thread. I'm mentioning the proposal also to apps-discuss@ and saag@lists as
this may be of interest to them too, but redirecting discussion to
this list so its all happening in one place.
Hi Wei,
Thanks for writing this down. I'm glad someone made the effort to come up
with an actual proposal rather than just shout about email being broken. I
think the document is well-written and clear on what it aims to achieve and
how it intends to do that. I do have some issues and concerns though.
In general, I don't think the following is adequately addressed: if I
don't want anyone but the intended recipient to read the email, then I
shouldn't send the message without encrypting the body - and possibly
shouldn't use email in the first place. If I can live with the limitations
of the store-and-forward principle of email, would I want to risk the email
not being delivered in case it can't be sent over secure connections?
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. 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.
What follows are some specific comments on the text.
1. Introduction
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.
2.3 DKIM
You last point applies is the closest to what's in the proposal though it
sounds like you have arguments that this should be changed that I would
like to explore. The proposal requests that the MSMD header should be
signed at least leaving the rest as implementation dependent. The
justification is to build on existing DKIM implementation with a minimum
requirement (and at some future point revisit DKIM via options).
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?
2.6. IMAP/POP3
If my mail server server were to support this extension and refuses to let
me download MSDM-messages through an unencrypted connection, is there any
reason why it would let me download other messages that way?
The difference is that MUA can let you reply or forward while typically a
downloaded mail is not transformed into to new derived content that gets
redelivered.
3. TLS
I would be very wary of explicitly specifying which cryptographic
protocols and which key lengths are to be used. Things tend to change. For
all we know, we may soon find out that RC4, with all its limitations, is
actually better than the alternatives. Or that new crypto-breaking
techniques mean that we'll need keys of twice the current length to provide
the same level of security.
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.
(I also wonder if, given how limited the security is provided by sending
email over secured channels, it actually makes sense to worry about RC4
being somewhat broken.)
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.
5. Recommendations
I don't claim to be an expert on user interfaces or in human understanding
of tehnical protocols, but do you really think that an average user can
make an informed decision on whether to use an option that requires secure
channels for email delivery, but still allows for the email to be read at
many placed along delivery route, while generating the bounce in case one
of the channels can't be adequately secured?
Yes this is an important argument, one that was argued over here as well,
and not fully resolved to everyone's satisfaction.
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.
-Wei
Martijn.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp