Re: [Gen-art] Gen-ART Last Call review of draft-baeuerle-netnews-cancel-lock-05

[Michael Bäuerle <[e-mail]>]

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