I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Not ready. The authentication in this document is single-use per article. I.e., once a single supersede or cancel is issued for an article, anybody can "forge" other valid supersedes or cancels for the same article. I assume that a cancel followed by a forged cancel is unimportant, but what about cancel->supersede, supersede->cancel, or supersede->supersede? Also, what about the race condition if the attacker can propagate the forgery faster than the original propagates? This document recommends calculating a single key K for each article (section 4), then publishing base64(hash(base64(K))) values for multiple different hash algorithms. This means that the preimage resistance of the weakest hash algorithm places an upper bound on the security of the authentication, even if the receiver ignores weaker algorithms. (An attacker who can calculate K from the weak hash can generate valid keys for the stronger hashes.) Additionally, while plenty of research goes into preimage security of individual hash algorithms, I don't think as much research goes into preimage security of multiple algorithms used in parallel on the same input. While I don't know of any non-brute-force attacks that can find X given sha256(X) and sha512(X), I see no reason that it wouldn't be easier than the easiest of the two individual preimage attacks. (I am not an expert though, there might be something I'm missing.) Section 4: Is it ever possible for two different (uid, mid) pairs to have the same concatenated value? E.g., alice@example.co + mfoo and alice@example.com + foo. If that ever happened and one of the two articles was canceled, an attacker would be able to cancel the other article. Section 4: I don't understand Q1. Are you asking me if the existing implementations are doing something insecure? (It's not specified well enough for me to tell.) Section 4: I think you should run any user-supplied password through a key derivation function before using it as a MAC key. Section 7: As I understand the terms, you care about preimage resistance, but not second preimage. (I think preimage covers finding any input that results in the specified output, not only the input that originally generated the specified output. But I might be misunderstanding the terms.) Section 7: I don't know where the minimum key sizes come from, but they seem a bit low to me. And for Q2, I don't know, sorry. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/