[rfc-i] RFC2119 requirements language in security considerations?
paul.hoffman at vpnc.org (Paul Hoffman) Thu, 07 April 2016 14:02 UTC
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu, 07 Apr 2016 11:02:22 -0300
Subject: [rfc-i] RFC2119 requirements language in security
considerations?
In-Reply-To: <56FAF0C2.6060000@KingsMountain.com>
References: <56FAF0C2.6060000@KingsMountain.com>
Message-ID: <8ABA5F91-97AF-471B-83F8-0C1D03EAA2B0@vpnc.org>
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. 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. 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. That way, the skimmers won't miss something that was really required. --Paul Hoffman
- [rfc-i] RFC2119 requirements language in security… =JeffH
- [rfc-i] RFC2119 requirements language in security… Paul Hoffman
- [rfc-i] RFC2119 requirements language in security… Brian E Carpenter
- [rfc-i] RFC2119 requirements language in security… Paul Hoffman
- [rfc-i] RFC2119 requirements language in security… Brian E Carpenter