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

"Shaun Cooley (shcooley)" <> Thu, 20 March 2014 06:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB8691A04AA; Wed, 19 Mar 2014 23:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.047
X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oRg_J7tTS_IF; Wed, 19 Mar 2014 23:32:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6BC2A1A04A7; Wed, 19 Mar 2014 23:32:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13235; q=dns/txt; s=iport; t=1395297117; x=1396506717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=91rF7iTzbe3SnqEytKXvl7hjaookA4DfAtQmp/hzHXo=; b=OQFymO5i1/tTBPivx+uvu/P5oiBUA/4dgTl7MPVCyZRPVeTt205e6F/3 asvLSslduPOa3UmFBGqyboluHk0X+2wUs4BFm9JKaktL6t8Y/RDyH+8vL farikCnGvmm+CnRW0/c+8dxjldaudq8iXNjoiIzfjcc1PPk76n5pmgRxQ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.97,692,1389744000"; d="scan'208,217"; a="28901678"
Received: from ([]) by with ESMTP; 20 Mar 2014 06:31:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s2K6VulI032601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 06:31:56 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 01:31:55 -0500
From: "Shaun Cooley (shcooley)" <>
To: "Murray S. Kucherawy" <>
Thread-Topic: secdir review of draft-ietf-appsawg-rrvs-header-field
Thread-Index: Ac9BrCh2zAg7BhNeSsS1/SZjUWgivABWhUsAAD8+2bA=
Date: Thu, 20 Mar 2014 06:31:55 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_187A7B1DA239514F9146FC78B19AADE30B6CC737xmbalnx10ciscoc_"
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Mar 2014 06:32:08 -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:

- – two uses of SHOULD NOT
- – two uses of SHOULD
- – two uses of SHOULD
- – one use of SHOULD
- – one use of RECOMMENDED
- – 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.


From: Murray S. Kucherawy []
Sent: Tuesday, March 18, 2014 12:01 PM
To: Shaun Cooley (shcooley)
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.


On Mon, Mar 17, 2014 at 12:03 AM, Shaun Cooley (shcooley) <<>> 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.