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

[David Mandelberg <[e-mail]>]

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., [e-mail] + mfoo and
>> [e-mail] + 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.


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