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

"HANSEN, TONY L" <> Thu, 01 December 2016 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E8E21294DD; Thu, 1 Dec 2016 14:20:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hnfYXS8jSC99; Thu, 1 Dec 2016 14:20:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE4E1129986; Thu, 1 Dec 2016 14:20:55 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id uB1JZVv7012558; Thu, 1 Dec 2016 14:43:04 -0500
Received: from ( []) by with ESMTP id 272sns1y9f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Dec 2016 14:43:03 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id uB1Jh1NX023123; Thu, 1 Dec 2016 14:43:01 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uB1JgpUb022871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Dec 2016 14:42:56 -0500
Received: from ( []) by (RSA Interceptor); Thu, 1 Dec 2016 19:42:44 GMT
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Thu, 1 Dec 2016 14:42:44 -0500
From: "HANSEN, TONY L" <>
To: Alexey Melnikov <>, Donald Eastlake <>, "" <>, "" <>
Thread-Topic: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review
Thread-Index: AQHSS3cWl89FzCeprU+TP5gi4HNBlKDzRHWAgAA6x4A=
Date: Thu, 01 Dec 2016 19:42:43 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_EDB1216EE0B349BEAE5D1FBE00AB9483attcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-01_17:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612010320
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 22:20:59 -0000

The wonderful thing about having a coauthor 5 hours ahead of you is that by the time you log in in the morning, things have often already been taken care of. ☺

Thanks for the comments Donald.


From: Alexey Melnikov <>
Date: Thursday, December 1, 2016 at 6:12 AM
To: Donald Eastlake <>, "" <>, "" <>
Cc: "" <>
Subject: Re: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review
Resent-From: <>
Resent-To: <>, <>, <>, <>, <>, <>, Barry Leiba <>
Resent-Date: Thursday, December 1, 2016 at 6:14 AM

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.


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?


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.


I do wonder if the references to X.400 mail are necessary. They seem archaic. Does anyone run X.400 email any more?

Yes :-)

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.