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

Barry Leiba <> Thu, 20 March 2014 14:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C9B0E1A0747; Thu, 20 Mar 2014 07:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Me52zLE-eN-H; Thu, 20 Mar 2014 07:53:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::232]) by (Postfix) with ESMTP id D03A71A046A; Thu, 20 Mar 2014 07:53:01 -0700 (PDT)
Received: by with SMTP id q108so2890084qgd.9 for <multiple recipients>; Thu, 20 Mar 2014 07:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AxOLkFsZ0EKrDr7y6OCj6d4HoFQCRaWylemD2pldIbI=; b=HVHk3pDasI31dt5Ozc8HvhBUKGn2byMdxjagWy841HRmd02SDCMNSqcGNKkgbASid2 osRMvCNzvBELFy/L2iKUzXihvxJMPmtoWXnDhlpaReBfMAH0a89e6oCk+4EFOvfLGAhV Bdt0lKWVA3pQBZd7uKlLIQlwSSGMQVaUKltcySDGQgb0JUv/6rxgAMe2kain6E/j+/Ui MlPoQHTJzcaRlT4I+p5+A26Exalbzgg2XHYAYwWfGShcVbWY/hNSg15C+eUk9TiZ9rqE 02uiRTCq3Va8T9b/nsGa8rkfue+nSCoknEr5p6qqLT0owXRYOZLqOlXkaXn/CWc6rsFb wN4w==
MIME-Version: 1.0
X-Received: by with SMTP id k36mr2217576qgd.51.1395327172554; Thu, 20 Mar 2014 07:52:52 -0700 (PDT)
Received: by with HTTP; Thu, 20 Mar 2014 07:52:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 20 Mar 2014 10:52:52 -0400
X-Google-Sender-Auth: AiX5y1zFo-_nefIoIFI237IYv10
Message-ID: <>
From: Barry Leiba <>
To: "Murray S. Kucherawy" <>
Content-Type: text/plain; charset="ISO-8859-1"
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 14:53:04 -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:

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.


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

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.


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