[babel] Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-babel-information-model-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the SECDIR review from Valery Smyslov.  Please review and respond
to the remaining items.  In particular, I concur with the recommendations about
precise language around the names of the parameters.

Section 3.1.  babel-implementation-version.  Is there any guidance on the
format of this string (or is it free form like a Server: in HTTP)?

Section 3.1.  babel-metric-comp-algorithms, babel-mac-algorithms,   
babel-dtls-cert-types.  Is there any guidance to provide on the delimiter
between a list of values, or is that explicitly a data model issue?

Section 3.1. babel-security-supported, babel-mac-algorithms,
babel-dtls-cert-types.  Consider providing citations on “MAC” and “DTLS”; and
“HMAC-SHA256” and “BLAKE2s”; and “X.509” and “RawPublicKey” (just like was done
for babel-metric-comp-algorithms).

Section 3.8.  babel-mac-key-value.

If the algorithm is based on the HMAC construction
      [RFC2104], 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 was under the impression that this was an information model to encode generic
Babel protocol parameter and that the underlying protocol documents fully
specified the normative behavior.  However, this guidance appears to be
introducing more restrictive configuration guidance not found in
draft-ietf-babel-hmac making this document an information model + profile.  Was
this intentional?

Section 3.8 and 3.9.  babel-mac-key-test and babel-cert-test.  It would be
useful to explain the use case for this testing API.

Section 5.  Note that operations are also exposed in the information model.

OLD
This document defines a set of information model objects and
   parameters that may be exposed to be visible from other devices

NEW
This document defines a set of information model objects,    parameters, and
operations that may be exposed to be visible from other devices

Section 5.  Per:

MAC keys are allowed to be as short as zero-length.  This is useful
  for testing.  Network operators are advised to follow current best
  practices for key length and generation of keys related to the MAC
  algorithm associated with the key.  Short (and zero-length) keys and
  keys that make use of only alphanumeric characters are highly
  susceptible to brute force attacks.

Add clarifying text that the information model explicitly enables this brute
force attack where most of the workload is pushed onto the server (since it
computes the hash).  Also add a mitigation.  Perhaps something like “This
information model provides an oracle via the babel-mac-key-test operation that
would enable such a brute force attack.  Operators SHOULD rate limit access to
this operation.”