Re: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review

Donald Eastlake <> Thu, 01 December 2016 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B99931297CD; Thu, 1 Dec 2016 09:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xl7tL1xy6mA1; Thu, 1 Dec 2016 09:22:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EFA81297B8; Thu, 1 Dec 2016 09:22:03 -0800 (PST)
Received: by with SMTP id c21so397907644ioj.1; Thu, 01 Dec 2016 09:22:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RcBa0QG/PDeOZHGOjzYKq9Ckl2bM1NANddHxCuWLiCw=; b=fW9XxJzy4lSWE8AM040JNfwAjvrvqT5HtG9wNWv1f8vcFrNGHQvwDd/uBQ7SvQyUt2 fFo4n5G1K1E8O39ijtHP6snjHPizaOxC1Y38PyCwtVgyGtsIJVfWu5a7OZby7k3wq80S xJb3+392Gi6QA1gexGYv+U1geIrfbkd5lGGe+tc6U9zJ/HA7x/QNm/tzQPrcUb79Tu03 SRhdEbzsEnJ28zMptYaR55ppLk+nbHHpRWYf+1CK3F9ynJ7Qk63ULO2N7zt+NLX6hzBB kt+4BasdpeJr9BUXW+DFe6ngsO92TgWp21oGG17GuLY+RL+Qqr7nKvOpmv2e4UFE62fC jYNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RcBa0QG/PDeOZHGOjzYKq9Ckl2bM1NANddHxCuWLiCw=; b=NEkwBvKVOJpPinTfr/aAv67eqDMESexOvHPfr51/jt39KQlCgSA+4Q8ZqAdfqFGk+Q 4xd0axIgEYnFV+UxR5ZJj8CTEpmPtIZYoIeHdbLoScfScAvWbTffD0wkBJzLHV6euhtd 2HaAchDiSL65XFUfDlcb5tKyrhWAeu6f/2uawZpRjYodjzX9v0ijiSXoSi3oU0gCr+bt xCs0DNWfecSFjqoJdAe/xHKpYvaYadvmHTLxXTgN5pklXV+c3RgfTWgdRHbS/Ot7sUBM f5V2WfeXtb5DWSf4VYqYni2P1rPZfLmKX0px6HUb4NPs/fJxC98PETqi6ApfPBON/kzb MsSw==
X-Gm-Message-State: AKaTC01L2Ja6anvWq1JEKmpoPadKzC45eutwdv+5IJ+YNZiWzwdj507sgWV6ejFygoVHSezD5e9S0xmqCSW8Vg==
X-Received: by with SMTP id e145mr31505533ita.14.1480612914759; Thu, 01 Dec 2016 09:21:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Dec 2016 09:21:39 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Thu, 01 Dec 2016 12:21:39 -0500
Message-ID: <>
To: Alexey Melnikov <>
Content-Type: multipart/alternative; boundary="001a114794eed58ec705429c0e79"
Archived-At: <>
Cc:, "" <>, "" <>
Subject: Re: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Dec 2016 17:22:06 -0000


On Thu, Dec 1, 2016 at 6:12 AM, Alexey Melnikov <>

> Hi Donald,
> Thank you for your comments.
> On 01/12/2016 02:02, Donald Eastlake wrote:
> My apologies for getting this in late. I have reviewed this document as
> part of the security directorate's ongoing effort to review all IETF
> documents being processed by the IESG. Document editors and WG chairs
> should treat these comments just like any other last call comments.
> This draft appears to be ready for publication with some nits..
> This draft polishes and advances to Internet Standard level RFC 3798 on
> Message Disposition Notifications.
> *Security Considerations:*
> The Security Considerations seem good except for one minor point: in my
> opinion the option to return all or a portion of the original message
> significantly increases the possible risk of use MDNs as a traffic
> multiplier. I believe this should be mentioned in Section 6.4.
> Thank you, I've added some text on this to the first paragraph of Section
> 6.4:
>   Additionally, as generated MDN notifications can include full content of
> messages that caused them
>   and thus they can be bigger than such messages, they can be used for
> bandwidth amplification attacks.


> *Miscellaneous:*
> The style of this draft is to say that you MUST do this and MUST NOT do
> that without indicating what action should be taken if this is violated.
> This is like saying a protocol field "MUST be zero" without adding the
> usual "and is ignored on receipt". For example, in Section 3 it says that a
> message disposition notification MUST NOT itself request an MDN. I believe
> it should go on and add the few words to say: "If one does, this is
> ignored." (unless that's wrong...) I'm not saying this must always be done
> but there may be 1 or 2 other cases like this in the draft where such
> wording should be added.
> This is a difficult area, because we typically don't describe how to
> handle violations of MUSTs. In the case that you mention above, the text is
> added in order to prevent loops. Not much can be done on recipients end
> other than usual handling of spam and/or broken implementations.
> Can you list other possible cases where you wanted some advice to be given?

Actually, this is the only one that really struck me...

> *Wording:*
> In Section 3, the wording of the last sentence of point d seems just a bit
> obscure. It says
>        However, in the case of encrypted messages requesting MDNs,
>        encrypted message text MUST be returned, if it is returned at
>        all, only in its original encrypted form.
> I think it would be a just bit clearer as
>        However, in the case of encrypted messages requesting MDNs, if
>        the original message or a portion thereof is returned, it MUST
>        be in its original encrypted form.
> I used your text, thank you.

You're welcome.

> *Trivia:*
> I do wonder if the references to X.400 mail are necessary. They seem
> archaic. Does anyone run X.400 email any more?
> Yes :-)

OK. Didn't know that.

> It is just used as an example, along with proprietary mail systems. I
> think such proprietary systems still exist, but X.400 mail? I'm not so
> sure. If it is going to be retained, maybe there should be an Informational
> reference for it.
> I will try to dig one out.

OK. I would guess there is some ITU X.400-19xx standard or something...

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA