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

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

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.

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

-- 
Michael Bäuerle