IETF Logo Mail Archive

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

Martijn Grooten <ietf-smtp@lapsedordinary.net> Wed, 16 October 2013 10:04 UTC

Return-Path: <ietf-smtp@lapsedordinary.net>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB4B11E8135 for <ietf-smtp@ietfa.amsl.com>; Wed, 16 Oct 2013 03:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpij5oUMieVC for <ietf-smtp@ietfa.amsl.com>; Wed, 16 Oct 2013 03:04:33 -0700 (PDT)
Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id E151011E8167 for <ietf-smtp@ietf.org>; Wed, 16 Oct 2013 03:04:29 -0700 (PDT)
Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id D1CD234130; Wed, 16 Oct 2013 10:04:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1381917868; bh=Pxd8PA2KK9Yinex/e3LJ1x7iA1RlUwSOrp3vgNkpyl0=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=qW0P4oP46kWot2+LfC1f5J0eMtMPk313/DnyoK8LKh58jG3QW0dT5aW5xZJCMTtOq Yr0ULTbETdgKCMFNnwMI3fDmtM+/bYQkrRQYPYDFVh3IQBj1P47jsoDZFRGwrLLcrB RmkZf0FzVLU6Chom1DycpC3sIQMnCMgUl7sjweXI=
Received: from localhost (localhost [127.0.0.1]) by mail.lapsedordinary.net (Postfix) with ESMTP id B375D3412E for <ietf-smtp@ietf.org>; Wed, 16 Oct 2013 10:04:28 +0000 (UTC)
Date: Wed, 16 Oct 2013 10:04:28 +0000
From: Martijn Grooten <ietf-smtp@lapsedordinary.net>
X-X-Sender: martijn@mail.lapsedordinary.net
To: ietf-smtp@ietf.org
In-Reply-To: <CAAFsWK1OROeda-=Ov9pGs=TpeDcxm=d6MDKVxw4Vi6X4LxWLYw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1310160908540.21431@mail.lapsedordinary.net>
References: <CAAFsWK1OROeda-=Ov9pGs=TpeDcxm=d6MDKVxw4Vi6X4LxWLYw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="2002081107-1306728897-1381917868=:21431"
Subject: Re: [ietf-smtp] Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd)
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-smtp>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 10:04:38 -0000

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.

v2.23.0 | Report a Bug | By Email