[rfc-i] RFC2119 requirements language in security considerations?
Brian E Carpenter
brian.e.carpenter at gmail.com
Thu Apr 7 13:01:12 PDT 2016
On 08/04/2016 02:02, Paul Hoffman wrote:
> On 29 Mar 2016, at 18:16, =JeffH wrote:
>> AFAICT, there is no "offical" admonition against one using RFC2119 requirements language in security/privacy considerations
>> sections, e.g...
>> 6. Security Considerations
>> 6.1. Downgrade Attacks
>> ..blah..blah.. The signature algorithm and key length
>> used in the foobar of type "bazfratz" MUST match the parameters
>> negotiated via [foo] extension.
>> ..however, it's been expressed in various places on-lists and verbally that some reviewers will object to it, and I was just
>> wondering whether there's someplace this guidance and rationale is written down where one can point others at it.
> I don't think it is written down anywhere.
I certainly hope not.
> This has been discussed occasionally in security WGs, with people noting that readers
> often only skim the Security Considerations section and thus might miss the requirements.
Seriously? After all these years you find that implementers don't read them, even when the
RFC2119 keywords are upper-cased?
> We can't prohibit giving requirements in the Security Consideration section, but we can suggest that all requirements there be
> copies of ones given earlier in the doc.
There may be cases where there is nowhere else in the document that a particular
requirement can logically be stated, which is why this really can't be more than
> That way, the skimmers won't miss something that was really required.
> --Paul Hoffman
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest