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

[Ballot comment]
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  is not supported by an implementation, the corresponding
    element MUST be skipped and potential following
  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  elements. "
This is hard to parse. Please consider active voice.

-4, last paragraph: Please include a reference for OpenSSL

[Ballot comment]
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."

[Ballot comment]
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  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.

[Ballot comment]
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  element with HMAC-SHA256 and  empty string as  (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.

[Ballot comment]
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].

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

[Ballot comment]
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  if multiple
    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.

[Ballot comment]
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 most likely handle it as an RFC Editor Note.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-baeuerle-netnews-cancel-lock-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Provisional Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

two early registrations will have their registrations made permanent by changing the references to: [ RFC-to-be ]

These are:

Cancel-Key
Cancel-Lock

Second, a new registry is to be created called the Netnews Cancel-Lock hash algorithm registry.

The new registry will be a new entry on the IANA matrix. IANA notes that the authors suggest that the new reigstry be made available at .

New entries in the registry are to be created through First Come, First Serverd as defined in [ RFC 5226 ]. In section 8.1, the authors provide a template for registration of new algorithms.

There are initial registrations in the new registry as follows:
-------+----------------+--------------+-----------------------------------------------------
Name Usage: Reference: Note:
-------+----------------+--------------+-----------------------------------------------------
md5 OBSOLETE [ RFC-to-be ] Do not use this algorithm anymore
sha1 LIMITED USE [ RFC-to-be ] This algorithm is intended for backward compatibility
sha224 LIMITED USE [ RFC-to-be ] sha256 should be used instead, this is a truncated variant of it
sha256 COMMON [ RFC-to-be ] This algorithm is mandatory to implement
sha384 LIMITED USE [ RFC-to-be ] sha512 should be used instead, this is a truncated variant of it
sha512 COMMON [ RFC-to-be ] This algorithm is optional


The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: draft-baeuerle-netnews-cancel-lock@ietf.org, alexey.melnikov@isode.com, julien@trigofacile.com, =?utf-8?q?Julien_=C3=89LIE?=
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Cancel-Locks in Netnews articles) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Cancel-Locks in Netnews articles'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-06-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an extension to the Netnews Article Format that
  may be used to authenticate the cancelling and superseding of
  existing articles.  If approved, this document updates RFC5537.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-baeuerle-netnews-cancel-lock/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-baeuerle-netnews-cancel-lock/ballot/


No IPR declarations have been submitted directly on this I-D.

My AD review:

You point to Section 6.8  of [RFC2045] for Base64 reference. Please update it to Section 4 of RFC 4648.

In Section 3.1: First thing you need to do is explain the purpose of the header field. One or two sentences should suffice.
I only figured out the purpose once I got to examples, so this is not great for readers not familiar with technology.

In Section 3.3: As above, please add a quick explanation of the purpose of the header field.

In Section 3.5:

1.  The  part of the  element is hashed using the
      algorithm defined by its  part.

is not defined anywhere else in the document. I think you meant  from Section 2.2.

In Section 4:

  This section is informative, not normative.

Should the algorithm described be at least RECOMMENDED? If you don't think so, I think saying here why this section is only informative is going to be helpful.

In Section 7:

Is guessing of MID for messages to be posted and cut & pasting it into a Cancel article a plausible security concern?


In Section 8.2:

  The IESG is considered to be the owner of all Netnews Cancel-Lock  hash algorithms that are on the IETF Standards Track.

I was looking for this text in Section 8.1. Is it worth also saying this in 8.1?

Shepherd Write-Up (Date: 2017-05-17)
draft-baeuerle-netnews-cancel-lock-04


1) Type of RFC
==============
The intended category of this document will be "Standards Track".
The intended status of this document will be "Proposed Standard".

This is the proper type of RFC because this document specifies a
long-standing authentication system that has been in use for more than
20 years with regards to Netnews articles.



2) Document Announcement Write-Up
=================================

Technical Summary
-----------------
This document defines an extension to the Netnews Article Format that
may be used to authenticate the cancelling and superseding of existing
articles.  If approved, this document updates RFC 5537.


Working Group Summary
---------------------
The draft was reviewed by a few NNTP and Netnews experts in
and .


Document Quality
----------------
Implementations of the mechanism already exist, like the canlock C
library or Perl hooks available for news servers.
News clients like Gnus, flnews, slrn or tin natively implement it.

Document Shepherd: Julien Elie
Responsible Area Director: Alexey Melnikov



3) Briefly describe the review of this document
===============================================
I have reviewed the document and checked that it correctly describes the
behaviour of existing implementations.  I reckon it is ready for
publication.



4) Shepherd concerns
====================
No concerns.



5) Further document review
==========================
Two questions (in Sections 4 and 7) are inline in the document for the
Security directorate review.  They were risen during discussions about
the document and just await for the validation by the Security directorate.



6) Document issues
==================
No issues (beyond the two remaining minor questions for the Security
directorate).



7) IPR disclosures
==================
The author confirmed that there is no IPR involved.



8) Has an IPR disclosure been filed that references this document?
==================================================================
Nothing known.



9) Consensus of the interested community behind this document?
==============================================================
There is consensus that the work Simon Lyall began in 1998 in
draft-ietf-usefor-cancel-lock should be updated to current usage and
standardized.  It will help future implementers.

At the same time, the insecure MD5 algorithm is phased out.  A IANA
registry is created to permit new algorithm names to be easily reserved
and used with this mechanism.



10) Has anyone threatened an appeal or indicated extreme discontent?
====================================================================
No.



11) ID nits
===========
== Too long line in Section 5.2

Maybe rewrite "uid+mid used as data, sec as secret key" as "uid+mid is
data, sec is secret key"?


== The document seems to contain a disclaimer for pre-RFC5378 work [...]
If you are able to get all authors (current and original) to grant those
rights, you can and should remove the disclaimer

I think Simon is still answering his mails.  He should be asked whether
he is willing to grant his rights so that the final document can be
released without the disclaimer.  Of course, if he does not want to, the
disclaimer should remain.


== Possible downref: Non-RFC (?) normative reference: ref. 'SHA'

As the "sha256" scheme is mandatory to implement, a reference to its
definition should be normative.
I suggest to move [SHA] to informative, and [RFC6234] (specifying
SHA-256) to normative.  Though RFC 6234 is Informational, it is present
in the Downref registry , so
it is fine.




12) Required formal review criteria
===================================
N/A.



13) Identification of all references as either normative or informative?
========================================================================
Yes.



14) Normative references to documents not ready for advancement?
================================================================
None.



15) Are there downward normative references (see RFC 3967)?
======================================================================
With RFC 6234 in the normative Section (see my previous comment in
question 11), it is a downref, already present in the Downref registry.



16) Status change of any existing RFCs?
=======================================
It updates RFC 5537 as noted in the title page header, listed in the
Abstract, and discussed in the Introduction.



17) Document Shepherd's review of the IANA Considerations Section
=================================================================
The IANA Considerations Section is consistent with the body of the
document.  The two new header field names and the four new algorithm
names are properly associated with a reservation in IANA registries.
The two referenced IANA registries are clearly identified.  The initial
contents of the algorithm names registry is detailed; allocation
procedures for future registrations are defined, and the name for the
registry is reasonable.



18) IANA registries that require Expert Review for future allocations
=====================================================================
None.


19) Reviews and automated checks performed to validate formal languages
=======================================================================
No automated checks, only a manual review.