Skip to main content

Cancel-Locks in Netnews Articles
draft-baeuerle-netnews-cancel-lock-09

Yes


No Objection

(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Eric Rescorla)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Warren Kumari
No Objection
Comment (2017-09-26 for -06) Unknown
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: <12345@mid.example>" 
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.
Alexey Melnikov Former IESG member
Yes
Yes (2017-09-25 for -06) Unknown
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].
Adam Roach Former IESG member
No Objection
No Objection (2017-09-26 for -06) Unknown
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.
Alia Atlas Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2017-09-27 for -06) Unknown
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
Deborah Brungard Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Eric Rescorla Former IESG member
(was Discuss) No Objection
No Objection (2017-12-02 for -08) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-09-28 for -06) Unknown
I support Eric's discuss and comments.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-09-27 for -06) Unknown
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."
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -06) Unknown