Cancel-Locks in Netnews Articles
updates
- rfc-5537 — Netnews Architecture and Protocols
Extracted elements (26)
A key design property of the Cancel-Lock system is that it prevents tracking of individual users: the Cancel-Lock header field exposes only a hash of the secret key, revealing no identity information, while the preimage (Cancel-Key) is published only at cancellation time. This differs from OpenPGP signatures, which are appropriate when public verifiability of originator identity is required.
SHA2 was chosen over SHA1 for the two mandatory schemes because: (1) the original USEFOR-CANCEL-LOCK spec is nearly two decades old and newsreader deployment is slow, so today's choice must remain strong for another 20 years; (2) SHA1 collision resistance is already broken, making it obsolete for TLS; (3) using SHA2 allows shared cryptographic library functions between Cancel-Lock and TLS implementations; (4) SHA3 was too recent and understudied at publication time.
The obs-scheme value "sha1" is deprecated and SHOULD NOT be generated. Serving agents SHOULD still accept it during a transition period as long as SHA1 is not considered unsafe or already marked OBSOLETE in the IANA registry. The obs-c-key-string syntax (unpadded Base64) SHOULD NOT be generated but MUST be accepted.
An injecting agent acting as representative for a posting agent without Cancel-Lock support MUST be able to positively authenticate the poster and MUST automatically add a working Cancel-Key header field for all cancel/supersede proto-articles from that poster.
Comments in CFWS (folding whitespace or inline comments) SHOULD NOT be generated in Cancel-Lock or Cancel-Key header fields because they can cause interoperability problems, but MUST be accepted by implementations.
Compliant implementations SHOULD generate valid Base64 for <c-key-string> (same syntax as c-lock-string) and MUST accept the relaxed obs-c-key-string syntax (1*base64-octet, allowing missing or invalid padding) for backward compatibility.
Each of the Cancel-Lock and Cancel-Key header fields MUST NOT occur more than once in an article.
If a <scheme> in a Cancel-Lock or Cancel-Key element is not supported, the corresponding element MUST be skipped and any following elements MUST NOT be ignored; processing continues with subsequent entries.
If an injecting agent or moderator acting as representative has added a Cancel-Lock element to the original article, it MUST add a Cancel-Key header field with at least one matching <c-key> element to any corresponding cancel or supersede article, given that it authenticates the poster as the same person.
If multiple <c-lock> elements are added or appended to the Cancel-Lock header field by a single agent, each element MUST use a unique key K (i.e., different secrets <sec>) to improve security.
Once an article is injected, the Cancel-Lock header field MUST NOT be altered; in particular, relaying agents beyond the injecting agent MUST NOT alter it. The same constraint applies to the Cancel-Key header field.
The hash algorithm "sha256" is mandatory to implement. Implementations SHOULD NOT use "sha224" or "sha384" to generate <scheme> values, as these are truncated variants registered only because existing implementations support them.
The local secret <sec> SHOULD have a length of at least the output size of the hash function used by the HMAC (256 bits / 32 octets for SHA256) and MUST be a cryptographically random value per RFC 4086.
The Cancel-Key header field contains a list of one or more <c-key> elements, each consisting of a scheme name and a Base64-encoded preimage value Base64(K). It is placed in cancel or supersede articles and reveals the secret key whose hash matches a Cancel-Lock entry in the target article.
The Cancel-Lock header field contains a list of one or more <c-lock> elements, each consisting of a hash algorithm scheme name and a Base64-encoded hash value computed as Base64(hash(Base64(K))). It is placed in an original article to enable future authentication of cancellation or supersede requests. Each header field MUST NOT occur more than once in an article.
The RECOMMENDED key derivation algorithm is K = HMAC(sec, uid+mid), where <sec> is a local secret, <uid> is the user's login name (empty string if each user has a dedicated secret), and <mid> is the full Message-ID including angle brackets. This avoids the need for a per-article key database.
This document establishes the "Netnews Cancel-Lock Hash Algorithms" registry at IANA (under netnews-parameters), with a First Come First Served registration policy. Initial entries are: md5 (OBSOLETE), sha1 (LIMITED USE, backward compatibility), sha224 (LIMITED USE), sha256 (COMMON, mandatory), sha384 (LIMITED USE), sha512 (COMMON, optional). Algorithm registrations MUST NOT be deleted; obsolete ones are marked OBSOLETE.
This document registers the Cancel-Lock and Cancel-Key header field names in the IANA "Permanent Message Header Field Names" registry under applicable protocol "netnews", status "standard", change controller IETF.
Because Cancel-Key values are published for every cancel or supersede request, an attacker who recovers the local secret <sec> (by breaking HMAC) can forge cancel/supersede authentication for all past articles whose Cancel-Lock was generated with that <sec>. Rotating <sec> at regular intervals mitigates this risk. Breaking only <scheme> allows forging a single article at a time.
Preimage resistance of the <scheme> hash function is the critical security property. A successful preimage attack either reveals the real Cancel-Key or produces a forgeable one, breaking the entire authentication system. Collision resistance is less important: finding two matching c-key elements for an arbitrary Cancel-Lock does not enable targeted forgery.
The Cancel-Lock/Cancel-Key authentication system provides no integrity checking. Arbitrary modifications can be applied to an article in transit regardless of Cancel-Key presence; a matching Cancel-Key only confirms that the cancellation was approved by a legitimate agent, not that the article is unmodified.
When a single agent adds multiple <c-lock> elements with different <scheme> values using the same K, a preimage attack on the weaker scheme may be easier because the attacker knows multiple hash outputs correspond to identical input. Agents MUST use distinct K values for each c-lock element to prevent this.
Authentication check (Section 3.5): For each supported <c-key> element, hash its c-key-string using the element's scheme; compare the result to each c-lock element with the same scheme in the original article. If any c-lock-string matches the hash, authentication passes and processing stops. If no match is found after all c-key elements are processed, authentication fails.
The Cancel-Key body uses ABNF: c-key-list = [CFWS] c-key *(CFWS c-key) [CFWS]; c-key = scheme ":" c-key-string; c-key-string = c-lock-string / obs-c-key-string. The c-key-string field encodes Base64(K), the plaintext preimage. Scheme names are case-insensitive.
The Cancel-Lock body uses ABNF: c-lock-list = [CFWS] c-lock *(CFWS c-lock) [CFWS]; c-lock = scheme ":" c-lock-string; c-lock-string = *(4base64-char) [base64-terminal]. The c-lock-string field encodes the Base64-encoded output of hash(Base64(K)), where K is the secret key.
The <scheme> token identifies the hash algorithm: scheme = "sha256" / "sha512" / 1*scheme-char / obs-scheme; scheme-char = ALPHA / DIGIT / "-" / "/". The value "sha256" is mandatory to implement; "sha512" is optional; "sha224" and "sha384" are limited-use; "md5" is obsolete.