RFC 8315

Cancel-Locks in Netnews Articles

📅 published February 2018, from ietf

Cancel-Locks in Netnews Articles 🦋

okay bestie, this is RFC 8315 and it's giving "proof that you can withdraw your post without the whole internet knowing it was you" ✨. It was written by M. Baeuerle at STZ Elektronik, and it's a Standards Track doc from February 2018 🎀. It updates RFC 5537 and doesn't obsolete anything. The ISSN is ISSN: 2070-1721. It's an IETF thing, so it went through the whole public review and got approved by the IESG 💅.

Abstract

this doc adds an extension to the Netnews Article Format so you can authenticate the withdrawal of articles that already exist 🫶. It also updates RFC 5537.

Status of This Memo

this is an Internet Standards Track document 🌸. It's a product of the IETF and it represents the consensus of the IETF community. Public review happened, and the IESG approved it for publication. For more on Internet Standards, check Section 2 of RFC 7841. Info about the current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc8315 🍓.

© 2018 IETF Trust and the persons identified as the document authors, all rights reserved 💜. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date, so read them carefully because they spell out your rights. Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥.

Table of Contents

1. Introduction ....................................................2
   1.1. Conventions Used in This Document ..........................3
2. Header Fields ...................................................3
   2.1. Cancel-Lock ................................................4
   2.2. Cancel-Key .................................................4
3. Use .............................................................5
   3.1. Adding an Initial Cancel-Lock Header Field to a
        Proto-Article ..............................................5
   3.2. Extending the Cancel-Lock Header Field of a Proto-Article ..6
   3.3. Adding a Cancel-Key Header Field to a Proto-Article ........6
   3.4. Extending the Cancel-Key Header Field of a Proto-Article ...7
   3.5. Check a Cancel-Key Header Field ............................7
4. Calculating the Key Data ........................................8
5. Examples ........................................................9
   5.1. Without UID ................................................9
   5.2. With UID ..................................................10
   5.3. Other Examples ............................................11
   5.4. Manual Checks .............................................12
6. Obsolete Syntax ................................................12
7. Security Considerations ........................................13
8. IANA Considerations ............................................15
   8.1. Algorithm Name Registration Procedure .....................16
   8.2. Change Control ............................................16
   8.3. Registration of the Netnews Cancel-Lock Hash Algorithms ...17
9. References .....................................................18
   9.1. Normative References ......................................18
   9.2. Informative References ....................................19
Acknowledgements ..................................................20
Author's Address ..................................................20

1. Introduction ✨

this authentication system is meant to be a simple way to check that a withdrawal of an article is legit 💖. Basically, the poster, posting agent, moderator, or injecting agent that handled the original article asked to pull it back, either with a cancel control article ([RFC5537] Section 5.3) or with a Supersedes header field ([RFC5537] Section 5.4).

This doc defines two new header fields, Cancel-Lock and Cancel-Key 🎀. The Cancel-Lock header field holds hashes of secret data. The preimages can later go into the Cancel-Key header field to authenticate a cancel or supersede request.

One property of this system is that it prevents tracking of individual users 🙈.

There are other authentication systems with different properties. If everybody should be able to verify who the originator is, for example for control articles that add or remove newsgroups ([RFC5537] Section 5.2), then an OpenPGP [RFC4880] signature is the better fit 🧚.

1.1. Conventions Used in This Document

any term not defined here has the same meaning it has in [RFC5536] or [RFC5537] 🌈.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they show up in all capitals, just like here 💅.

2. Header Fields

this section lays out the formal syntax of the new header fields using ABNF [RFC5234] 🦋. Non-terminals that aren't defined here are defined in Section 3 of [RFC5536].

The new header fields Cancel-Lock and Cancel-Key are defined by this doc, and they extend the list of article header fields from [RFC5536] ✨.

Each of these header fields MUST NOT occur more than once in an article.

Both new header field bodies hold lists of encoded values. Every entry is based on a <scheme>:

scheme       = "sha256" / "sha512" / 1*scheme-char / obs-scheme
scheme-char  = ALPHA / DIGIT / "-" / "/"

The hash algorithms for <scheme> are defined in [RFC6234]. See also [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1, and [SHA] for the SHA2 family 🌸. The Base64 encoding is defined in Section 4 of [RFC4648].

This doc defines two values for <scheme>: "sha256" and "sha512". The hash algorithm "sha256" is mandatory to implement 🔥.

Since the hash algorithm for <scheme> can't be negotiated, unnecessary proliferation of hash algorithms should be avoided 💀. The hash algorithms "sha224" and "sha384" are only added to the "Netnews Cancel-Lock Hash Algorithms" registry (Section 8.3) because implementations exist that support them. Implementations SHOULD NOT use the hash algorithms "sha224" and "sha384" to generate <scheme>.

2.1. Cancel-Lock

cancel-lock     = "Cancel-Lock:" SP c-lock-list CRLF
c-lock-list     = [CFWS] c-lock *(CFWS c-lock) [CFWS]
c-lock          = scheme ":" c-lock-string
c-lock-string   = *(4base64-char) [base64-terminal]
base64-char     = ALPHA / DIGIT / "+" / "/"
base64-terminal = 2base64-char "==" / 3base64-char "="

comments in CFWS (comments and/or folding whitespace) can cause interoperability problems 😭, so comments SHOULD NOT be generated but MUST be accepted.

If <scheme> isn't supported by an implementation, the matching <c-lock> element MUST be skipped, and any <c-lock> elements that come after it MUST NOT be ignored 🎀.

<c-lock-string> is the Base64-encoded output of a hash operation (defined by <scheme>) run on the Base64-encoded key "K". The key is meant to authenticate the person or agent that created or processed the proto-article, up to and including injection 🧚:

Base64(hash(Base64(K)))

because the hash operation is one-way, the key "K" never gets revealed 🙈.

2.2. Cancel-Key

cancel-key   = "Cancel-Key:" SP c-key-list CRLF
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

comments in CFWS can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted 💖.

If <scheme> isn't supported by an implementation, the matching <c-key> element MUST be skipped, and any <c-key> elements that come after it MUST NOT be ignored.

<c-key-string> is the Base64-encoded key "K" that was used to create the <c-lock> element in the Cancel-Lock header field body (as defined in Section 2.1 of this document) of the original article:

Base64(K)

the relaxed syntax for <c-key-string> above is required for backward compatibility with implementations that don't follow this spec 🫶. Compliant implementations SHOULD generate valid Base64 (that is, the syntax of <c-lock-string> from Section 2.1 of this document), and they MUST accept strings of <base64-octet> characters (that is, the syntax of <obs-c-key-string> from Section 6 of this document).

3. Use

these are the use cases 👑:

  • The poster of an article wants to cancel or supersede existing articles.
  • A moderator wants the ability to cancel articles after approving them.
  • An injecting agent wants to act as a representative for a posting agent that has no support for the authentication system described in this document.
  • A news administrator wants the ability to cancel articles that were injected by its system (because, for example, they violate its abuse policy).

3.1. Adding an Initial Cancel-Lock Header Field to a Proto-Article

A Cancel-Lock header field MAY be added to a proto-article by the poster or posting agent, and it will include one or more <c-lock> elements 🦋.

If the poster or posting agent doesn't add a Cancel-Lock header field to a proto-article, then an injecting agent (or moderator) MAY add one, including one or more <c-lock> elements ✨.

If multiple <c-lock> elements are added to the Cancel-Lock header field by a single agent, each <c-lock> element MUST use a unique key "K" to improve security 🔐.

If an injecting agent (or moderator) wants to act as a representative for a posting agent without support for the authentication system described in this document, then it MUST be able to positively authenticate the poster, and it MUST be able to automatically add a working Cancel-Key header field for all proto-articles with cancelling or superseding attempts from that poster 🌸.

Other agents MUST NOT add this header field to articles or proto-articles that they process 🙅.

3.2. Extending the Cancel-Lock Header Field of a Proto-Article

If a Cancel-Lock header field has already been added to a proto-article, then any agent further processing the proto-article, up to and including the injecting agent, MAY append additional <c-lock> elements to the ones already in the header field body 💅.

If multiple <c-lock> elements are appended to the Cancel-Lock header field by a single agent, each <c-lock> element MUST use a unique key "K" to improve security 🔥.

If an injecting agent (or moderator) wants to act as a representative for a posting agent without support for the authentication system described in this document, then the same requirements apply as those mentioned in Section 3.1 🫶.

Once an article is injected, this header field MUST NOT be altered. In particular, relaying agents beyond the injecting agent MUST NOT alter it 🔒.

3.3. Adding a Cancel-Key Header Field to a Proto-Article ✨

okay so the Cancel-Key header field is basically where you show your receipts 🧾💅. It contains one or more of the secret strings that were used to create the Cancel-Lock header field of the original article. Knowing at least one of those secret strings is required to create a match for successful authentication 🔐.

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, and it will include one or more <c-key> elements. They correspond to some or all of the <c-lock> elements in the article referenced by the Control (with a "cancel" command as defined in [RFC5537]) or Supersedes header field.

If, as mentioned in Section 3.1, an injecting agent or moderator (acting as a representative for the posting agent) has added a Cancel-Lock header field to an article listed in the Control (with a "cancel" command as defined in [RFC5537]) or Supersedes header field, then (as long as it authenticates the poster as being the same as the poster of the original article) it MUST add the Cancel-Key header field with at least one <c-key> element that corresponds to that article. 🫶

Other agents MUST NOT alter this header field. 🙅‍♀️

3.4. Extending the Cancel-Key Header Field of a Proto-Article 🦋

If a Cancel-Key header field has already been added to a proto-article, then any agent further processing the proto-article up to the injecting agent (inclusively) MAY append additional <c-key> elements to the ones already in the header field body. Think of it like adding more keys to the same key ring 🔑💜.

If, as mentioned in Section 3.2, an injecting agent or moderator (acting as a representative for the posting agent) has extended the Cancel-Lock header field in an article listed in the Control (with a "cancel" command as defined in [RFC5537]) or Supersedes header field, then (as long as it authenticates the poster as being the same as the poster of the original article) it MUST extend the Cancel-Key header field body with at least one <c-key> element that corresponds to that article.

Once an article is injected, this header field MUST NOT be altered. Relaying agents beyond the injecting agent MUST NOT alter it either. The lock is locked, bestie 🔒.

3.5. Check a Cancel-Key Header Field 🔍

When a relaying or serving agent receives an article that tries to cancel or supersede a previous article via a Control (with a "cancel" command as defined in [RFC5537]) or Supersedes header field, the system defined in this document can be used for authentication. The general handling of articles containing these attempts, as defined in [RFC5537], is not changed by this document. No changes to the existing rules, just a new way to prove you're the real deal 🌿.

To process the authentication, the received article has to contain a Cancel-Key header field, and the original article has to contain a Cancel-Lock header field. If that isn't the case, the authentication is not possible (failed) 💀.

For the authentication check, every supported <c-key> element from the received article gets processed like this:

  1. The <c-key-string> part of the <c-key> element is hashed using the algorithm defined by its <scheme> part.
  2. For each <c-lock> element with the same <scheme> in the original article, its <c-lock-string> part is compared to the calculated hash.
  3. If a <c-lock-string> part is equal to the calculated hash, the authentication is passed, and the processing of further elements can be aborted 🎉.
  4. If no match was found and there are no more <c-key> elements to process, the authentication failed 😭.

4. Calculating the Key Data 🧮

The following algorithm is RECOMMENDED to calculate the key "K" based on a local secret <sec>. 💖

K = HMAC(sec, uid+mid)

That's the key "K" for an article with a Message-ID <mid> that belongs to the User-ID (or UID) <uid> (for example, the login name of the user). The Hashed Message Authentication Code (HMAC) is outlined in [RFC2104]. The HMAC is computed over the data <uid+mid> (where "+" means concatenation), using <sec> as a secret key that's held locally and can be reused for multiple articles. This method removes the need for a per-article database containing the keys used for every article. Lowkey genius 🧠✨.

A posting agent has to add the Message-ID header field to the proto-article itself, and it uses the content of the header field body as <mid> (excluding whitespace but including the literal angle brackets) 🎀.

The User-ID <uid> must not contain angle brackets. This makes sure that concatenating different <uid> and <mid> elements can't give the same results 🙅‍♀️.

A posting agent that uses a dedicated local secret <sec> for every user should use an empty string for the <uid> part.

In general, different values for the secret <sec> must be used if multiple <c-lock> elements are added by a single agent. 🔐

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 it must be a cryptographically random value [RFC4086]. Random means random, no "password123" energy here 🙈.

Note that the hash algorithm used as the base for the HMAC operation is not required to be the same as the one specified by <scheme>. An agent that verifies a Cancel-Key header field body simply checks whether one of its <c-key> elements matches one of the <c-lock> elements with the same <scheme> in the Cancel-Lock header field body of the original article.

Common libraries like OpenSSL can be used for the cryptographic operations. 💅

5. Examples 🎀

5.1. Without UID 🙈

Here's example data for creating a <c-lock> element with HMAC-SHA256 and an empty string as <uid> (as recommended in Section 4 for posting agents):

Message-ID: <12345@mid.example>

mid: <12345@mid.example>
sec: ExampleSecret
K  : HMAC-SHA256(sec, mid) ;mid used as data, sec as secret key

Calculating Base64(K) with the OpenSSL command-line tools in a POSIX shell:

$ printf "%s" "<12345@mid.example>" \
  | openssl dgst -sha256 -hmac "ExampleSecret" -binary \
  | openssl enc -base64
qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=

This can be used as <c-key-string> for cancelling or superseding the article <12345@mid.example>. 🍓

Calculating Base64(SHA256(Base64(K))), which is required for <c-lock-string>, with the OpenSSL command-line tools in a POSIX shell:

$ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64
s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

Inserted into the Cancel-Lock header field body of the article <12345@mid.example>, it looks like this:

Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

Inserted into the Cancel-Key header field body of an article that should cancel or supersede the article <12345@mid.example>, it looks like this:

Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=

5.2. With UID 👑

Here's example data for creating a <c-lock> element with HMAC-SHA256 and "JaneDoe" as <uid> (as recommended in Section 4):

Message-ID: <12345@mid.example>

uid: JaneDoe
mid: <12345@mid.example>
sec: AnotherSecret
K  : HMAC-SHA256(sec, uid+mid) ;uid+mid as data, sec as secret key

Calculating Base64(K) with the OpenSSL command-line tools in a POSIX shell:

$ printf "%s" "JaneDoe<12345@mid.example>" \
  | openssl dgst -sha256 -hmac "AnotherSecret" -binary \
  | openssl enc -base64
yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=

This can be used as <c-key-string> for cancelling or superseding the article <12345@mid.example>.

Calculating Base64(SHA256(Base64(K))), which is required for <c-lock-string>, with the OpenSSL command-line tools in a POSIX shell:

$ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64
NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

Inserted into the Cancel-Lock header field body of the article <12345@mid.example>, it looks like this:

Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

Inserted into the Cancel-Key header field body of an article that should cancel or supersede the article <12345@mid.example>, it looks like this:

Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=

5.3. Other Examples 🌈

Another matching pair of Cancel-Lock and Cancel-Key header fields:

Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=
Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=

With obsolete syntax (this uses a <c-key-string> with invalid or missing Base64 padding) 🫠:

Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4=
Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF

Let's assume that all the examples above are associated with the same article (for example, created by different agents) 🧚:

Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=
             sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=
             sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=
             sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4=
Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=
            sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
            sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=
            ShA1:aaaBBBcccDDDeeeFFF

Remember that parsing for <scheme> must be case insensitive. 🧐

5.4. Manual Checks 🔎

Manual checks using the OpenSSL command-line tools in a POSIX shell:

$ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64
s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

$ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64
NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

$ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64
RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=

$ printf "%s" "aaaBBBcccDDDeeeFFF" \
  | openssl dgst -sha1 -binary \
  | openssl enc -base64
bNXHc6ohSmeHaRHHW56BIWZJt+4=

6. Obsolete Syntax 🕰️

Earlier draft versions of this spec defined a different value for <scheme> than this version does. The following value for <scheme> is now deprecated and SHOULD NOT be generated anymore. Serving agents SHOULD still accept it for a transition period, as long as the corresponding hash function is not considered unsafe (see Section 7 for details) or already marked as OBSOLETE in the "Netnews Cancel-Lock Hash Algorithms" registry (Section 8.3). 🙏

obs-scheme = "sha1"

It's important for backward compatibility that the deprecated value for <scheme> doesn't get phased out too early. Security and compatibility concerns should be carefully weighed before choosing to remove <obs-scheme> from existing implementations (or to skip implementing it in new ones) this is a "read the room" moment 🫣.

Earlier draft versions of this specification allowed a more liberal syntax for <c-key-string>:

obs-c-key-string = 1*base64-octet
base64-octet     = ALPHA / DIGIT / "+" / "/" / "="

<obs-c-key-string> SHOULD NOT be generated but MUST be accepted. 🌸

7. Security Considerations 🔐

okay bestie, this part is SERIOUS so grab a snack 🍓. The authentication system in this doc gives you literally zero integrity checking 💀. Arbitrary changes can be made to an article on its way through the network, Cancel-Key header or no Cancel-Key. All a serving agent learns from a Cancel-Key header field with a matching <c-key> element is that the withdrawal of the target article was approved by a legit person or agent. That's the whole tea ☕.

Example: a valid <c-key> gets pulled out of a cancel control article and shoved into a forged supersede article 😱. Every server that gets the forged supersede before the cancel control article should accept it. And honestly, anyone can post with forged identity info in the header (same energy as spam email), so the same result can be achieved by sending a fake new article with no authentication system at all 🙈.

For originator and integrity checks, a signature-based authentication system is required 🖊️ (normally OpenPGP [RFC4880] is used for this purpose). Both systems can be combined 🫶.

The important property of the hash function used for <scheme> is preimage resistance 👑. A successful preimage attack either reveals the real Cancel-Key (the one used to create the Cancel-Lock of the original article) or gives a different Cancel-Key that also matches a Cancel-Lock. Either way, this would break the authentication system defined in this document 💀.

Collision resistance of the hash function used for <scheme> is less important 🤷‍♀️. Finding two <c-key> elements for the Cancel-Key header field that match a <c-lock> element of an arbitrary Cancel-Lock header field doesn't help break this authentication system (if a specific article is defined as the target). The only damage possible is collateral damage from arbitrary cancel or supersede.

Currently, there is no known practicable preimage or second preimage attack against the hash function SHA1 ✨. Therefore, there is no hurry to replace it. The reasons why this document specifies hash functions from the SHA2 family are:

  • The previous specification of this authentication system, [USEFOR-CANCEL-LOCK], is nearly two decades old. Client-side implementations are moving forward extremely slowly too (newsreaders from the last millennium are still in heavy use 😭). What is defined today should be strong enough for the next two decades or so.
  • The collision resistance of SHA1 is already broken, so it is now obsolete for digital signatures as used in Transport Layer Security (TLS) 💔. It is intended that an implementation of this authentication system can share the same cryptographic library functions that are used for TLS.
  • It is intended that the same hash function can be used for <scheme> and (as the base) for the HMAC that is recommended in Section 4. See notes below for HMAC-MD5 and HMAC-SHA1 🔁.
  • The SHA2 family of hash algorithms is widely supported by cryptographic libraries 📚. In contrast, SHA3 is currently too recent and has not been studied enough to be considered more secure than SHA2.

The operation HMAC(sec, uid+mid) as recommended in Section 4 must be able to protect the local secret <sec> 🔒. The Message-ID <mid> is public (it's in the Message-ID header field body), and <uid> is optional. An attacker who wants to steal or use a local secret only needs to break this algorithm (regardless of <scheme>), because Cancel-Key header fields are explicitly published for every request to cancel or supersede existing articles 🚨.

Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is desired to have a greater margin for security here. Breaking <scheme> only allows the authentication of a single forged cancel or supersede request. With <sec> in hand, it is possible to forge such requests for all articles that contain Cancel-Lock header field bodies with elements that were generated with this <sec> in the past. Changing <sec> at regular intervals can be used to mitigate potential damage 🛡️.

If an agent adds or appends multiple <c-lock> elements, it must not use the same K for them (by using different secrets (<sec>)) 🙅‍♀️. Adding multiple <c-lock> elements with the same <scheme> and the same K makes no sense (because it would result in identical <c-lock> elements). That means the case of different <scheme> values is the relevant one: a preimage attack on the different hash algorithms may be easier if the attacker knows the output of those hash algorithms was created with the same input 👀.

If an implementation chooses to not implement the key calculation algorithm recommended in Section 4, or to implement it with the HMAC based on a different hash function than <scheme>, the key size used should match the output size of the hash function used for <scheme> 🎀.

8. IANA Considerations 🌸

IANA has registered the following header fields in the "Permanent Message Header Field Names" registry, following the procedures set out in [RFC3864] 🗂️:

   Header field name: Cancel-Lock
   Applicable protocol: netnews
   Status: standard
   Author/change controller: IETF
   Specification document(s): RFC 8315

   Header field name: Cancel-Key
   Applicable protocol: netnews
   Status: standard
   Author/change controller: IETF
   Specification document(s): RFC 8315

The "Netnews Cancel-Lock Hash Algorithms" registry is maintained by IANA 🦋.

The registry is available at <https://www.iana.org/assignments/netnews-parameters/> ✨.

8.1. Algorithm Name Registration Procedure

IANA will register new Cancel-Lock hash algorithm names on a First Come First Served basis, as defined in BCP 26 [RFC8126] 📝. IANA has the right to reject obviously bogus registration requests but will perform no review of claims made in the registration form.

Registration of a Netnews Cancel-Lock hash algorithm is requested by filling in the following template and sending it via electronic mail to IANA at <iana@iana.org> 💌:

   Subject: Registration of Netnews Cancel-Lock hash algorithm X
   Netnews Cancel-Lock hash algorithm name:
   Security considerations:
   Published specification (recommended):
   Contact for further information:
   Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
   Owner/Change controller:
   Note: (Any other information that the author deems relevant may be
      added here.)

Any name that conforms to the syntax of a Netnews Cancel-Lock hash algorithm (see the definition of <scheme> in Section 2) can be used 🏷️. In particular, Netnews Cancel-Lock algorithms are named by strings consisting of letters, digits, hyphens, and/or slashes.

Authors may seek community review by posting a specification of their proposed algorithm as an Internet-Draft 🧑‍💻. Netnews Cancel-Lock hash algorithms intended for widespread use should be standardized through the normal IETF process, when appropriate.

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

8.2. Change Control

Once a Netnews Cancel-Lock hash algorithm registration has been published by IANA, the owner may request a change to its definition 🔄. The change request follows the same procedure as the initial registration request.

The owner of a Netnews Cancel-Lock hash algorithm may pass responsibility for the algorithm to another person or agency by informing IANA. This can be done without discussion or review 🤝.

The IESG may reassign responsibility for a Netnews Cancel-Lock hash algorithm. The most common reason would be to enable changes to algorithms where the owner of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community 🥺.

Netnews Cancel-Lock hash algorithm registrations MUST NOT be deleted 🚫. Algorithms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" field. Such algorithms will be clearly marked in the registry published by IANA 🪦.

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

8.3. Registration of the Netnews Cancel-Lock Hash Algorithms

This section gives a formal definition of the Netnews Cancel-Lock hash algorithms, as required by Section 8.1 for the IANA registry 📋.

   Netnews Cancel-Lock hash algorithm name: md5
   Security considerations: See Section 7 of this document
   Published specification: RFC 8315
   Contact for further information: Author of this document
   Intended usage: OBSOLETE
   Owner/Change controller: IESG <iesg@ietf.org>
   Note: Do not use this algorithm anymore

   Netnews Cancel-Lock hash algorithm name: sha1
   Security considerations: See Section 7 of this document
   Published specification: RFC 8315
   Contact for further information: Author of this document
   Intended usage: LIMITED USE
   Owner/Change controller: IESG <iesg@ietf.org>
   Note: This algorithm is intended for backward compatibility

   Netnews Cancel-Lock hash algorithm name: sha224
   Security considerations: See Section 7 of this document
   Published specification: RFC 8315
   Contact for further information: Author of this document
   Intended usage: LIMITED USE
   Owner/Change controller: IESG <iesg@ietf.org>
   Note: sha256 should be used instead; this is a truncated variant
   Netnews Cancel-Lock hash algorithm name: sha256
   Security considerations: See Section 7 this document
   Published specification: RFC 8315
   Contact for further information: Author of this document
   Intended usage: COMMON
   Owner/Change controller: IESG <iesg@ietf.org>
   Note: This algorithm is mandatory to implement

   Netnews Cancel-Lock hash algorithm name: sha384
   Security considerations: See Section 7 of this document
   Published specification: RFC 8315
   Contact for further information: Author of this document
   Intended usage: LIMITED USE
   Owner/Change controller: IESG <iesg@ietf.org>
   Note: sha512 should be used instead; this is a truncated variant

   Netnews Cancel-Lock hash algorithm name: sha512
   Security considerations: See Section 7 of this document
   Published specification: RFC 8315
   Contact for further information: Author of this document
   Intended usage: COMMON
   Owner/Change controller: IESG <iesg@ietf.org>
   Note: This algorithm is optional

9. References 📚

the reference list picks up in the next part, so hang tight 🧚✨

9.1. Normative References 📚✨

okay bestie, these are the must-reads. the spec leans on them and you can't skip them 💅

9.2. Informative References 🌸

these ones are the extra reading. not required to build the thing, but SO good for context 🧚

Acknowledgements 🫶💜

the author gives a huge shoutout to Simon Lyall, who came up with the original Cancel-Lock authentication system, as written up in [USEFOR-CANCEL-LOCK]. Simon wrote that original document and said yes to using his work here, and honestly this whole spec is mostly built on what he made 👑 (fun fact: it was first meant to be revision 02, but it got renamed because the USEFOR IETF WG is closed now 🥲).

Thank you also to Russ Allbery, Urs Janssen, Richard Kettlewell, Marcel Logen, Holger Marzen, Dennis Preiser, and Emil Schuster for sharing ideas and reviewing the spec. Big thanks as well to Peter Faust and Alfred Peters for the stats on which algorithms are actually in use right now 📊✨

And special thanks to the Document Shepherd, Julien Elie, and the responsible Area Director, Alexey Melnikov 🎀 these two are literally the MVPs of this doc 🌈

Author's Address 💌

Michael Baeuerle
STZ Elektronik
Hofener Weg 33C
Remseck, Baden-Wuerttemberg  71686
Germany

Fax:   +49 7146 999061
Email: michael.baeuerle@stz-e.de
📦 where this page comes from