Re: [babel] HMAC: removed constraint on the key stored in interface table

["STARK, BARBARA H" <[e-mail]>]

I’m unclear – which “implementation” are we talking about? A babel-mac implementation or a data model?

I still think I would prefer something in info model like (the Courier font is existing text):

      The value of the HMAC key.  An implementation MUST
      NOT allow this parameter to be read.  This can be done by always
      providing an empty string when read, or through permissions, or other means.
      This value MUST be provided when this instance is created, and is
      not subsequently writable. The key length MUST be the maximum length that is
              defined for the associated babel-mac-key-algorithm, so there is no need for the MAC algorithm to zero-pad,
              truncate, or otherwise manipulate the key prior to use. For HMAC-SHA256, this is defined
              in RFC4868 as 64 bytes. For Blake2s, this is defined in RFC7693 as 32 bytes. If keys are
              generated from user input, the user interface or management system is expected to
              zero-pad strings that are less than the required length, and prohibit strings longer than
              the required length. This ensures the delivered string is exactly the required number of bytes.

I really dislike SHOULDs and wiggle room in things like this that can cause a complete breakdown of interoperability. Hashing is an area where it’s very easy to achieve non-interoperability.
Barbara

From: David Schinazi <[e-mail]>

@Juliusz: Revised statement, now with 30% more thinking of the children:

(only added second normative statement)

- Keys used for Babel-MAC MUST be of a length suitable for that MAC function.
- Implementations MUST accept all key lengths that are suitable for the selected MAC function, as defined by the specification of that MAC function.
- Implementations MUST reject keys that are not suitable for the MAC function; in other words, implementations MUST NOT preprocess keys of unsuitable lengths to produce a key of suitable length.
- Babel management interfaces MUST NOT allow configuring keys of non suitable lengths.
- Keys for HMAC-SHA256 SHOULD be 64 bytes long, keys for Blake2s SHOULD be 32 bytes long.

@Barbara: I'm not discussing the user interface, only what the information model can deliver to the Babel implementation

On Tue, Aug 13, 2019 at 4:13 PM Juliusz Chroboczek <[e-mail]<mailto:[e-mail]>> wrote:
> See response to Juliusz. The info model is *not* designing a user interface. It
> is stating what it will (or is allowed to) deliver to the babel implementation.
> What happens to generate the bytes that get delivered to babel by the info
> model are outside the control of the info model (so normative language is no
> good). Those proposed SHOULD statements mean the info model really can deliver
> pretty much any string to a babel implementation and expect interoperable
> results.

If I read Barbara right:

  - administrator writes a script that configures his 10000 routers the way
    he likes it;
  - administrator buys a new router that interprets the data model differently;
  - script breaks because the new router requires exactly 64 bytes in a key;
  - administrator spends the weekend fixing his network rather than going
    hiking with his children as he promised.

Think of the children, David.

-- Juliusz