Re: [babel] info-model: preparing -09 on github

[Juliusz Chroboczek <[e-mail]>]

Barbara suggested:

> This value is of a length suitable for the associated
> babel-mac-key-algorithm.  If the algorithm is based on the HMAC
> construction, the length MUST be between 0 and the block size of the
> underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as
> described in {{RFC4868}}).  If the algorithm is "BLAKE2s", the length
> MUST be between 0 and 32 bytes inclusive, as described in {{RFC7693}}.

I fully support this formulation.

David commented:

> However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk where 0
> <= kk. I don't think the information model should express an opinion as to
> whether keys longer than 64 bytes are safe or not.

What is suggested by 6234 is to hash longer keys.  By doing that, we'd be
implying that Babel-HMAC is suitable for use with a human-entered
keyphrase.  Since Babel-HMAC is trivially vulnerable to brute-force
attacks, this is not a good idea.  (I'll add a few words on this subject
to the security considerations of Babel-MAC.)

Ideally, Babel-HMAC should be used with a randomly drawn key.  In this
case, the person drawing the key can draw a key of arbitrary length, and
32 bytes is a good choice for both algorithms.  (Using a key larger than
the hash size, while technically possible, does not increase security to
my knowledge.)

If use of a passphrase is desired, then the key should be derived using
a KDF that makes brute-force attacks difficult, such as PBKDF2 or bcrypt.
In that case, the original passphrase should be kept on a secure host
(e.g. the network administator's carefully secured laptop), and only the
resulting key be communicated through the management interface.  Since key
derivation functions are parametrisable in the size of the output key, the
hashing procedure described for HMAC is not used.

Finally, our goal is to get these protocols deployed by real people; thus,
we should not forbid the use of short keys for testing.  A UI should
perhaps display a warning for a key with low entropy (either a short key
or a key that contains multiple repeated strings, e.g. 123412341234...),
but it should not prevent if from being used.

In conclusion, Barbara's formulation above suits me.  If you wish to
change it, please preserve the two following properties:

  - make it clear that it's a key, not a passphrase;
  - allow short keys.

-- Juliusz