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

From: David Mandelberg <[email-masked]>
Date: Mon, 3 Jul 2017 14:46:34 -0400

On 06/28/2017 12:09 PM, Michael Bäuerle wrote:
> David Mandelberg wrote:
>>
>> [...]
>> 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.)
> 
> The option to add multiple entries with different hash algorithms in
> the new draft is intended for the transition period. SHA1 (as defined
> in the old draft from Simon Lyall) was used for decades and it is
> unlikely that all existing implementations will add SHA2 support
> quickly.
> 
>> 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.)
> 
> Suggested additional words for Section 4 (Calculating the key data):
> 
>   In general every agent must not use the same secret <sec> if
>   multiple <c-lock> elements are added.

Section 4 is only a RECOMMENDED way to calculate K, so I don't think
adding anything to section 4 is sufficient. I'd suggest adding something
to section 2.1 like: "If multiple <c-lock> are present in a
<c-lock-list>, each <c-lock> MUST use a unique key K." Adding text to
Section 4 would be good too though.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: David Mandelberg <[email-masked]>
Date: Mon, 3 Jul 2017 14:53:06 -0400

On 06/29/2017 01:53 PM, Michael Bäuerle wrote:
> David Mandelberg wrote:
>>
>> [...]
>> Section 4: Is it ever possible for two different (uid, mid) pairs to
>> have the same concatenated value? E.g., [email-masked] + mfoo and
>> [email-masked] + foo. If that ever happened and one of the two
>> articles was canceled, an attacker would be able to cancel the other
>> article.
> 
> Literal angle brackets at start and end must be part of mid (words are
> already present in Section 4).
> 
> Adding additional words that forbid angle brackets in uid would make an
> overlap impossible (the first opening angle bracket would always be the
> junction point in this case).
> Suggestion for additional words in Section 4:
> 
>    The User-ID <uid> must not contain angle brackets.

If imposing that requirement is acceptable, then that does solve the
security issue.

> 
>> 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.)
> 
> Q1 is there because the draft intentionally does not formalize the
> algorithm used by some existing implementations that support uid:
> 
>                              HMAC(data, secret key)
>    Existing            : K = HMAC(mid, uid+sec)
>    Recommended by draft: K = HMAC(uid+mid, sec)
> 
> It is unclear why existing implementations with support for uid are
> using it in a specific way (there was no User-ID in the old draft from
> Simon Lyall).
> 
> It is assumed that uid may be easy to guess - probably simply the
> users name.
> The choice for the latter option from the two above was done because:
> - mid is public and sec is secret
>   If uid is easy to guess, it is more related to mid than to sec.
> - HMAC has two input channels (data and key)
>   If sec is our secret key, other information should be feeded into
>   the data input.
> - Section 4 defines recommendations for the length of sec
>   This definition would be more complicated (and the recommendations
>   harder to implement) if some potentially non-secret data with non-
>   constant length is concatenated to sec.
> 
> The question is why existing implementations have chosen uid+sec as
> secrect key (maybe I have overlooked an advantage of this option) and
> whether the different choice uid+mid as data really is the better option.

Gotcha. I really don't know why they would put the uid in the secret key
input to HMAC. I think your HMAC(uid+mid, sec) is better.

---

From: David Mandelberg <[email-masked]>
Date: Mon, 3 Jul 2017 15:01:36 -0400

On 06/30/2017 12:31 PM, Michael Bäuerle wrote:
> 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?

Sorry, I don't have a lot of experience with KDFs. From what I
understand, I think you want to pick something that is computationally
difficult, and can be made more difficult over time as computers get
more powerful. (To make attacks against the password closer in
complexity to brute-force attacks against the output of the KDF.)

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

Yup, that would work if you don't need to support passwords.

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

Looks good.