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