Re: [secdir] secdir review of draft-baeuerle-netnews-cancel-lock-05

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

David Mandelberg wrote:
> 
> [...]
> Section 4: I think you should run any user-supplied password through a
> key derivation function before using it as a MAC key.

The obvious solution would be HKDF, but RFC5869 says in section 4:
| 
| [...] Applications interested
| in a password-based KDF should consider whether, for example,
| [PKCS5] meets their needs better than HKDF.

Would PKCS5 (RFC8018) be a good solution for this purpose?

A workaround would be to change the words from section 4 of the draft:
| 
| The local secret <sec> should have a length of at least the output
| size of the hash function that is used by HMAC (256 bit / 32 octets
| for SHA256). If the secret is not a random value, but e.g. some sort
| of human readable password, it should be much longer. In any case it
| is important that this secret can not be guessed.

to:

   The local secret <sec> should have a length of at least the output
   size of the hash function that is used by HMAC (256 bit / 32 octets
   for SHA256) and must be a random value.

This would simply push the problem beyond the scope of the document.

> 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.)

If second preimage always is associated with known input, then I have
used the wrong term and paragraph 1 in section 7 should say:

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

-- 
Michael Bäuerle