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

From: "Shaun Cooley (shcooley)" <[email-masked]>
Date: Mon, 17 Mar 2014 07:03:48 +0000

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Mar 2014 12:00:30 -0700

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) <
[email-masked]> 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
>

---

From: "Shaun Cooley (shcooley)" <[email-masked]>
Date: Thu, 20 Mar 2014 06:31:55 +0000

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:[email-masked]]
Sent: Tuesday, March 18, 2014 12:01 PM
To: Shaun Cooley (shcooley)
Cc: [email-masked]; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> 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.

-Shaun

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 20 Mar 2014 01:36:42 -0700

On Wed, Mar 19, 2014 at 11:31 PM, Shaun Cooley (shcooley) <
[email-masked]> wrote:

>  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".
>
>
>
I can't recall the exact reason why it's been said that RFC2119 language
ought not be used in Security Considerations (or similar) prose, or which
document's development cycle brought it up, but my general recollection is
that those words were intended to convey aspects of interoperability having
to do with protocol elements, and not otherwise.  It would appear this
opinion has formed since RFC3552 was published, since obviously there's a
conflict between them.  But like I said, it does seem to vary depending on
who and when one is asking.  Could also be the person(s) who told me this
are actually plain wrong.

I'm happy to take direction from the sponsoring AD on this one.

-MSK

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Mar 2014 10:58:53 +0000

> I'm happy to take direction from the sponsoring AD on this one.

I'm sure you'll get that.

FWIW, from my POV there should be no magical interactions between
RFC section headings and RFC 2119. You should do what makes sense
and is more clear for the reader. That can and often does include
using e.g. a 2119 MUST in the security considerations section.

In other words, I figure the folklore you describe above ought be
ignored and/or corrected. I do not believe that's written down
anywhere in an RFC or IESG statement, if you find it is, please let
me know and I'll try get it fixed.

S.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Mar 2014 11:05:58 +0000

On 20/03/2014 10:58, Stephen Farrell wrote:
> ignored and/or corrected.
Agreed.
> I do not believe that's written down
> anywhere in an RFC or IESG statement,
I don't think so either.

I think the main argument against RFC 2119 language in Security 
Considerations sections is that people are not going to read them while 
implementing specs (and they might only read them later when considering 
security aspects). But I think this is nonsense.
> if you find it is, please let me know and I'll try get it fixed.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Mar 2014 10:52:52 -0400

>> and VRRP) include normative language:

First, let's please separate "2119 key words" from "normative
language", and be sure we don't fall under the mistaken impression
that language isn't normative unless it's in all caps.  If a Security
considerations section says, "Farble attack is possible if you don't
wiffle, so it's essential that servers wiffle," that's a normative
requirement for servers to wiffle, whether or not the magic word
<strike>"please"</strike> "MUST" is used.

Now...

> to do with protocol elements, and not otherwise.

That's the silliest thing I've ever heard.[1]

May I disabuse y'all of that idea forthwith?  Yes?  Good.  Thank you.

The document tells us how to implement the protocol.  The whole
document does, from the tippy-top of the Introduction head to the
soles of the References feet.  Normative stuff can appear anywhere,
and if it makes sense to put some in the Security Considerations
section, then that's where we should put it.

Now, I *would* have an issue with the organization of the document if
protocol elements were defined only in the Security Considerations,
and there might be times when security aspects should be normatively
specified where the protocol elements were defined, and only
highlighted in the Security Considerations, or whatnot.  But that's a
question of organization of a particular document.  This document is
well organized, and I have no issues with that.

So if you (for whatever value of "you", which here seems like Shaun,
with Murray in basic agreement) think that the normative language in
the Security Considerations is not sufficiently clear or strong, and
would benefit from some 2119 key words, make it so.  Do it with care
and thought, but don't have any silly ideas that 2119 key words don't
belong in security considerations sections.  They belong where they
are needed, and not where they aren't.

> I'm happy to take direction from the sponsoring AD on this one.

So let it be written; so let it be done.

Barry

[1] Actually, not really: I've heard some pretty damnfool things in my
life, some far sillier than any of us can imagine.  But a little
hyperbole never hurt an argument.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 20 Mar 2014 10:39:39 -0700

> May I disabuse y'all of that idea forthwith?  Yes?  Good.  Thank you.
[...]

Given that Shaun's original comment identified these as nits: "What mighty
contests arise from trivial things."

I've made his changes in the next version, which I'll post after the
telechat unless you want them sooner.  The only other pending change is a
language tweak in IANA Considerations that came up during their review of
that section.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Mar 2014 15:23:10 -0400

Go aheand and post now, so the IESG is reviewing the very latest version.
 T'anks.

b

On Thursday, March 20, 2014, Murray S. Kucherawy <[email-masked]>
wrote:

> On Thu, Mar 20, 2014 at 7:52 AM, Barry Leiba <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> > wrote:
>
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 20 Mar 2014 12:28:59 -0700

Done.

On Thu, Mar 20, 2014 at 12:23 PM, Barry Leiba <[email-masked]>wrote:

>> Given that Shaun's original comment identified these as nits: "What
>> mighty contests arise from trivial things."
>>