Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field

["Shaun Cooley (shcooley)" <[e-mail]>]

While RFC 3552 (“Guidelines for Writing RFC Text on Security Considerations”) does not specify whether or not Security Considerations should include normative language, both of the examples in section 6 (SMTP and VRRP) include normative language:

- 6.1.1.2 – two uses of SHOULD NOT
- 6.1.1.3 – two uses of SHOULD
- 6.1.1.7 – two uses of SHOULD
- 6.2.1.1 – one use of SHOULD
- 6.2.1.2 – one use of RECOMMENDED
- 6.2.1.3 – two uses of RECOMMENDED

I don’t see why we wouldn’t want to include normative language in the Security Considerations – especially SHOULD.  The definition from BCP14/RFC2119 of “there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course” seems like exactly what the Security Considerations are getting at: “the authors thought about this, and suggest you do X, unless you have a specific reason and fully understand the implications of not following the authors’ suggestion”.

EKR – care to weigh in?

MSK – Seeing that you are more or less in agreement with adding the normative language, I’ll split this discussion to a new thread if this goes more than  two (or so) replies on this thread.

-Shaun

From: Murray S. Kucherawy [mailto:[e-mail]]
Sent: Tuesday, March 18, 2014 12:01 PM
To: Shaun Cooley (shcooley)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: secdir review of draft-ietf-appsawg-rrvs-header-field

Barry, what's your take on these? I'm still under the impression that Security Considerations shouldn't include normative language, but the opinions on this seem to vary from one person and one week to the next.
Otherwise, they appear reasonable to me.

-MSK

On Mon, Mar 17, 2014 at 12:03 AM, Shaun Cooley (shcooley) <[e-mail]<mailto:[e-mail]>> wrote:
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines an extension for SMTP called RRVS, along with a new MAIL header field called Require-Recipient-Valid-Since, that allows senders to indicate to receivers the last date when the sender confirmed the ownership of the target mailbox with the intended recipient, with a goal of preventing sensitive mail from being delivered to the wrong party if the ownership of a mailbox has changed.

The document is easy to understand and covers several information disclosure issues that might arise from abuse of the RRVS extension or matching header.  I consider this document to be ready for publication with two small nits:

 - The suggested abuse countermeasures described in 14.1 should be reworded to indicate that operators SHOULD (or are RECOMMENDED to) implement countermeasures against RRVS probing.

 - The suggested use restrictions described in 14.2 should be reworded to indicate that operators SHOULD (or are RECOMMENDED to) accept any RRVS datetime as valid for accounts that have only had a single owner, even if the RRVS datetime predates the creation of the target account.

-Shaun