Paul Kyzivat wrote: > On 7/11/17 2:39 PM, Michael Bäuerle wrote: > > Paul Kyzivat wrote: > > > > > > [...] > > > But in that case, what is the point of passing the scheme around at all? > > > > The <scheme> part of <c-key> elements serve the following purposes: > > - Backward compatibility > > Existing implementations use it this way since many years > > - Define the hash algorithm to apply on <c-key-string> elements > > - Select corresponding <c-lock-string> elements to compare against > > > > > IIUC doing so doesn't add any additional security or privacy. You could > > > simply pass the hashed value in cancel-key. Then the verifying agent > > > wouldn't do any hashing. > > > > In this case the creator of the Cancel-Key header field would not prove > > that he really knows K. > > > > > This would mean that the cancel-key would be > > > checked against locks that used a different hash, but that shouldn't > > > hurt anything. > > > > Yes, it is unlikely that comparing against <c-lock-string> elements, > > that used a different hash algorithm, will hurt. > > > > But changing the general syntax of the header fields would break > > backward compatibility to existing implementations. This should be > > avoided with highest priority. > > I studied the draft further. I finally get that it is simpler than I was > expecting it to be. So really it is just that the lock contains > hash(password) while the key contains the password. (The key is just an > algorithmically generated password.) I couldn't believe you would really > be passing the password in the clear, since that would expose it to > on-path attack. But I guess your assumption is that this is really a > one-time password, and that if it is correct then it will immediately be > invalidated, and if it is wrong then it doesn't matter.
Yes, it is one-time (only matching one target article). This is the reason why the recommended algorithm in Section 4 uses the unique Message-ID as base component to calculate K. Because the Message-ID is public, a second component (local secret) is used to calculate K. The HMAC algorithm must protect this local secret, so that it cannot be calculated from the resulting K (that is intended to be published inside the Cancel-Key header field). Even with on-path attacks the relevant properties should stay intact: 1) An attacker should not be able to generate valid K values for foreign articles himself 2) An attacker should not be able to use hijacked K values to cancel different articles (than intended by the legitimate creators of these K values) As a result, only legitimate persons/agents should be able to approve cancels for existing articles. Integrity protection for new articles is not a provided property. Supersedes are not more than cancels combined with new articles. > So I'll withdraw my concerns on this section, except that maybe it could > be clearer. Specifically, section 3 could be more explicit about what > each distinct actor (poster, posting agent, moderator or injecting > agent) does. The document is labeled to update RFC 5537. The general behaviour of agents is already documented there: <https://tools.ietf.org/html/rfc5537#section-3.4> ff. Specific agent behaviour regarding to this document is, in general, limited to the principle described in Section 3: A moderator or injecting agent that uses Cancel-Locks must be able to authenticate the author and act representitive for the author (if no Cancel-Lock/-Key header field is present). Maybe this is too strict and moderators and injecting agents should be allowed to add the Cancel-Lock header field only for themselves too. -- Michael Bäuerle
pgpbGUIGnqoCk.pgp
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
