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

From: David Mandelberg <[email-masked]>
Date: Sat, 10 Jun 2017 00:26:31 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the  security
area directors.  Document editors and WG chairs should treat  these
comments just like any other last call comments.

The summary of the review is Not ready.

The authentication in this document is single-use per article. I.e.,
once a single supersede or cancel is issued for an article, anybody can
"forge" other valid supersedes or cancels for the same article. I assume
that a cancel followed by a forged cancel is unimportant, but what about
cancel->supersede, supersede->cancel, or supersede->supersede? Also,
what about the race condition if the attacker can propagate the forgery
faster than the original propagates?

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

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.

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

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

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

Section 7: I don't know where the minimum key sizes come from, but they
seem a bit low to me. And for Q2, I don't know, sorry.

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

---

From: Michael Bäuerle <[email-masked]>
Date: Wed, 28 Jun 2017 17:18:35 +0200

David Mandelberg wrote:
> [...]

Hi David,

yes, there is no integrity protection. But this is not considered a
problem (see below).

The current words in the introduction may implicitly suppose some
integrity protection capabilities. Suggestion for better words:

   The authentication system defined in this document is intended to be
   used as a simple method to verify that the withdrawal of an article
   is valid, that is to say either the poster, posting agent, moderator
   or injecting agent that processed the original article has required
   to withdraw it via the use of a cancel control article (RFC5537
   Section 5.3) or a Supersedes header field (RFC5537 Section 5.4).

And maybe the following additional words for Section 7 (Security
Considerations) as explanation:

   The authentication system defined in this document provides no integrity
   checking properties. Arbitrary modifications can be applied to an article
   on its way through the network, regardless of the presence of a Cancel-Key
   header field. A serving agent, who receives an article that contains a
   Cancel-Key header field with a matching <c-key> element, only get the
   information that the withdrawal of the target article was approved by a
   legitimate person or agent.

   Example: A valid <c-key> element is extracted from a cancel control
   article and inserted into a forged supersede article. All servers on the
   network that receive the forged supersede article before the cancel control
   article should accept the forged supersede.
   But because everybody can post articles with forged identity information in
   the header (same as with spam e-mail), the same result can be achieved by
   sending a forged new article using no authentication system at all.

   For originator and integrity checks a signature based authentication system
   is required (normally OpenPGP RFC4880 is used for this purpose).
   Both systems can be combined.

-- 
Michael Bäuerle

---

From: Michael Bäuerle <[email-masked]>
Date: Wed, 28 Jun 2017 18:09:33 +0200

David Mandelberg wrote:
> 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

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.

-- 
Michael Bäuerle

---

From: Michael Bäuerle <[email-masked]>
Date: Thu, 29 Jun 2017 19:53:37 +0200

> articles was canceled, an attacker would be able to cancel the other

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.

> implementations are doing something insecure? (It's not specified well

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

---

From: Michael Bäuerle <[email-masked]>
Date: Fri, 30 Jun 2017 18:31:22 +0200

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

> 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