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

[Donald Eastlake <[e-mail]>]

Hi,

On Thu, Dec 1, 2016 at 6:12 AM, Alexey Melnikov <[e-mail]>
wrote:

> 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.
>

OK.


>
>
> *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...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]