[Top] [All Lists]

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

2013-10-16 05:04:42
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?

ietf-smtp mailing list