Cancel-Locks in Netnews articles
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Eric Rescorla Discuss
The proper use of HMAC as a KDF is to have the secret value be used as the key and the public value used as the value, not the other way around. Even then, it would be better to use HKDF.
Line 225 secret strings can later be used to authenticate a cancel or supersede request. This document would be easier to read if this section was earlier up. I had to kind of infer that you were sending hashes and then using preimages to cancel. Line 235 o An injecting agent acts representitive for posting agents without support for the autentication system described in this document. This is ungrammatical. Line 236 o An injecting agent acts representitive for posting agents without support for the autentication system described in this document. Nit: authentication. Line 239 o A news administrator wants the ability to cancel articles that were injected by its system (because they e.g. violate its abuse policy). Nit: "e.g." has a trailing comma and also needs a real phrase afterwards as in "e.g., they violate" Line 252 If an injecting agent (or moderator) wants to act representitive for a posting agent without support for the authentication system See above. Line 358 K = HMAC(uid+mid, sec) IMPORTANT: The proper use of HMAC as a PRF is to have the secret value be used as the key and the public value used as the value, not the other way around. Line 380 In general every agent must not use the same secret <sec> if multiple <c-lock> elements are added. Why don't you instead generate this as: HMAC(sec, uid || mid || scheme). Line 384 size of the hash function that is used by HMAC (256 bit / 32 octets for SHA256) and must be a random value. This should state "cryptographically random" and cite RFC 4086. Also, I don't understand the requirement to have a minimum length of the size of the hash. That's not an HMAC requirement and doesn't make sense if you're not coupling it to the shash you are using. Line 647 recommendations remain in the document, or does an RFC exist to refer to with regards to security recommendations? ]] I don't see where these values would come from. The size should be orthogonal to the hash function, and if you did want to match it, should be the same size. also, you need to cite RFC 4086 here too.
Alexey Melnikov Yes
The GenArt ABNF issue was resolved by posting in erratum on RFC 5536. A small tweak to the ABNF in this document is needed to match. I suggest the following RFC Editor Note: Replace the first 3 paragraphs at the beginning of Section 2: OLD: This section describes the formal syntax of the new header fields using ABNF [RFC5234]. It extends the syntax in Section 3 of [RFC5536] and non-terminals not defined in this document are defined there. The [RFC5536] ABNF should be imported first before attempting to validate these rules. The new header fields Cancel-Lock and Cancel-Key are defined by this document, they follow the rules described in [RFC5536] Section 2.2: fields =/ *( cancel-lock / cancel-key ) NEW: This section describes the formal syntax of the new header fields using ABNF [RFC5234]. It extends the syntax in Section 3 of [RFC5536] and non-terminals not defined in this document are defined there. The new header fields Cancel-Lock and Cancel-Key are defined by this document, extended the list of article header fields defined in in [RFC5536].
Alia Atlas No Objection
Deborah Brungard No Objection
Ben Campbell No Objection
Substantive: -1.2: Who does this section address? Do you expect it to stay in the final RFC text? Do you expect readers to do something about it? -2.1 "If <scheme> is not supported by an implementation, the corresponding <c-lock> element MUST be skipped and potential following <c-lock> elements MUST NOT be ignored." I'm not sure I understand the intent. Only the first may be skipped? What if following elements also do not support the scheme? (repeats in 2.2) -7: I'm surprised there's not a stronger recommendation to combine this with a signature-bases authentication system. It seems like a cancel or supersedes article should have at least the same level of protection as the original article. Editorial: -1, first paragraph: "... agent that processed the original article has required to withdraw..." s/required/requested -1.1, first sentence: "Any term not defined in this document has the same meaning as it does in [RFC5536] or [RFC5537]." That seems unlikely to be true in any formal sense. Please consider enumerating the terms that are imported from those RFCs. Or failing that, say something to the effect of "The terminology from RFCs 5536 and 5537 are incorporated as defined in those documents." -3, third bullet: "An injecting agent acts representitive for posting agents without support for the autentication system described in this document." Should this day "acts as a representative" or "acts on behalf of"? (Pattern occurs several times throughout.) -3.3: "A Cancel-Key header field MAY be added to a proto-article containing a Control or Supersedes header field by the poster or posting agent which will include one or more <c-key> elements. " This is hard to parse. Please consider active voice. -4, last paragraph: Please include a reference for OpenSSL
Spencer Dawkins No Objection
Suresh Krishnan No Objection
Warren Kumari No Objection
I have some comments and nits, but please keep in mind that I'm really not a new expert, so apologies if some of these are obvious. Section 1. Introduction "or injecting agent that processed the original article has required to withdraw it via the use of a cancel control article" I think that this is actually "requested", not "required" --AFAICT, the person doing this cannot really enforce that this is done, and so the best that they can do is request that this happens. Or, if they really can, perhaps "... that processed the original article is withdrawing it via the use of a cancel control article". "One property of this system is that it prevents tracking of individual users" - I disagree. This method / technique itself doesn't prevent tracking of individual users -- what it does (as far as I understand) is allow users to cancel / supersede / etc postings without being tracked if they choose to use this. Section 2.1. Cancel-Lock This is hard to follow without examples -- please mention that there *are* examples further in the doc; they are helpful, but only if you know they exist :-) "Comments in CFWS can cause interoperability problems" -- please expand CFWS (perhaps a link to RFC 5322 Section 3.2.2 ?) Section 3. Use "This secret strings can" s/This/These (plural) "An injecting agent acts representitive " - perhaps "acting as representative" or "acts as the". Also, representitive is misspelled I think (also in S3.1) "Other agents MUST NOT add this header field to articles or proto- articles that they process." -- OK, but what if they do? What if the injecting agent / moderator *doesn't* do add this, but someone else does? Can they then cancel the posting when they otherwise wouldn't be able to? (As I said, I have no idea how new normally works, just wondering if allows an external party to escalate privileges). Section 5.1: "Example data for creation of a <c-lock> element with HMAC-SHA256 and empty string as <uid> (as suggested in Section 4 for posting agents): Message-ID: <firstname.lastname@example.org>" Is the message-ID strongly tied to the article? E.g can an attacker somehow attach a message ID (from A) to a different body / article (from B), and then when A gets cancelled, use this to also cancel B? Just like above, I really have no idea how Message-IDs are generated / used, so a simple "No, that's stupid!" is fine :-)) Just like above, mentioning that the examples exist would be helpful higher up in the document.
Mirja Kühlewind No Objection
Thanks Paul for the gen-art review! My understanding is that this final change will be requested with an RFC editor note and as such the document can move forward. Not sure if the rules for the new registry must be defined that extensively in this document as they seem to be inline with the usual procedures as defined in RFC8126. However, I guess that's not a problem. Nit: Maybe make this one explicitly normative: OLD "The hash algorithm "sha256" is mandatory to implement." NEW "The hash algorithm "sha256" is REQUIRED to implement."
Terry Manderson No Objection
Kathleen Moriarty No Objection
I support Eric's discuss and comments.
Alvaro Retana No Objection
Adam Roach No Objection
Thanks for a very easy to read and understand document. I have a small number of questions/comments. Section 1.2 gives instructions for representations of names that cannot be accurately displayed with the ASCII character set. Who is the target audience here? If these are intended as instructions for the RFC editor, I note that the current policy is: "no additional non-ASCII documents... will be published until the new format tools are in production." If these are intended as notes to the reader, they're fine (although I might suggest phrasing it as a note for the reader in that case). Section 2 contains the following text: "Because the hash algorithm for <scheme> cannot be negotiated, unnecessary proliferation of hash algorithms should be avoided." Section 8.1, however, defines a first-come-first-served registration policy for these schemes. In light of the observation made in section 2, can you explain why this policy was chosen? Section 3.5 has the following instructions for Cancel-Key validators: To process the authentication, the received article must contain a Cancel-Key header field and the original article a Cancel-Lock header field. If this is not the case, the authentication is not possible (failed). A literal reading of this is that: if I get a cancellation with a "Cancel-Key" in it, but the corresponding article has no "Cancel-Lock," then authentication fails and the article is *not* canceled. This seems to have some unfortunate failure modes when injectors transition from not using this mechanism to using it: since the generation of the key K is performed statelessly, the injector will not know whether an article originally contained a "Cancel-Lock," and will therefore insert a "Cancel-Key" into the cancelling article. If the original article was injected before the cancel lock mechanism was activated, this would then cause the cancellation to fail. Is that the intention? Finally, it may be worth including some information about how rotation of the secret used to generate the various keys K might be achieved.