[secdir] FW: [babel] Secdir last call review of draft-ietf-babel-information-model-11

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

This was the response Valery sent.

-----Original Message-----
From: Valery Smyslov <[e-mail]> 
Sent: Monday, November 09, 2020 1:40 AM
To: STARK, BARBARA H <[e-mail]>
Subject: RE: [babel] Secdir last call review of draft-ietf-babel-information-model-11

Hi Barbara,

please, see inline.

> Hi Valery,
> I've cut this down to just the points that still need some discussion. Thx,
> Barbara
> 
> > > > Issues.
> > > >
> > > > 1. Section 3.1:
> > > >
> > > >    babel-mac-algorithms:  List of supported MAC computation algorithms.
> > > >       Possible values include "HMAC-SHA256", "BLAKE2s".
> > > >
> > > > BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the
> > > > desired
> > > > size of the MAC is a parameter for it. Where the size of MAC is specified?
> > For
> > > > HMAC with SHA256 I can at least imagine that full 256 bits output is used
> > as a
> > > > MAC...
> > >
> > > Juliusz said:
> > > > Right.  The intent is that Blake2s is used with 32-octet keys and 16-octet
> > > > hashes (collision-resistance is not a concern for Babel-MAC while
> > > > dictionary attacks are).  Barbara, I think that you should explicitly
> > > > state that Blake2s implies 128-bit hashes.  (You may also consider
> > > > renaming BLAKE2s to BLAKE2s-128.)
> > >
> > > The defined values for babel-mac-algorithms come directly from draft-ietf-
> > babel-hmac. The defined value
> > > names should map closely to the names used for the algorithms in in that
> > draft -- which they currently do.
> > >
> > > If it needs to be explicitly stated somewhere that an implementation of
> > draft-ietf-babel-hmac with BLAKE2s
> > > outputs 128-bit MACs, then draft-ietf-babel-hmac (which was already
> > submitted for publication) would be the
> > > correct place to say that. The information model is not the right place,
> > unless there's some expectation for the
> > > size to be configurable or reportable. I'm not seeing any request for the
> > MAC size to be configured or reported
> > > via the information model.
> > >
> > > I'm proposing no change to the defined values of babel-mac-algorithms in
> > order to maintain complete
> > > consistency with the names used in draft-ietf-babel-hmac-12.
> >
> > My point was that the intent Juliusz mentioned (that Blake2s is used with 32-
> > octet keys and 16-octet
> > hashes) must be documented somewhere. If you think it must be in the
> > draft-ietf-babel-hmac,
> > I'm fine with this, but currently I cannot find any such requirement
> > anywhere.
> 
> I had a chat with Juliusz and Toke. We discussed that we think
> draft-ietf-babel-hmac should mention the MAC size a BLAKE2s
> implementation should create. This draft is currently in
> the RFC Editor's Queue, but the preference would be to include this
> before publication. This has been taken to the babel WG list
> to get consensus there. There is some discussion as to whether it
> should be 128-bit or 256-bit. Juliusz included Valery on the WG thread.

Yes, I received those messages. Thanks.

> With that, I would also change the suggested string here in the info model
> to "BLAKE2s-<agreed-upon bit length>", just in case someone wanted to
> do BLAKE2s with different length MACs.
> Will this be acceptable?

Absolutely!

> > > > 2. Section 3.9:
> > > >
> > > >    babel-cert-test:  An operation that allows a hash of the provided
> > > >       input string to be created using the certificate public key and
> > > >       the SHA-256 hash algorithm.  Input to this operation is a binary
> > > >       string.  The output of this operation is the resulting hash, as a
> > > >       binary string.
> > > >
> > > > I failed to understand what this operation should do. Literally reading it is
> > > > intended to produce SHA2-256 hash of public key and some arbitrary
> > string
> > > > (concatenated? in what order?). But then I failed to understand the
> > purpose
> > > > of
> > > > this test. I would have understood if this operation provides signing of
> > the
> > > > arbitrary string using private key and SHA2-256 as a hash function
> > (similarly
> > > > to babel-mac-key-test), but it in not what is written...
> > >
> > > One of the most common problems in configuring security mechanisms is in
> > the format of the input key (hex,
> > > ASCII, base64, hashing that occurs to create "actual key", etc.). When a
> > security mechanism fails to work, it is
> > > important for users or device managers to be able to trouble-shoot this
> > specific point of failure. This test
> > > allows the user/manager to see if what this device thinks the MAC should
> > be is the same as what another
> > > device thinks the MAC should be or is the same as the MAC being sent on
> > the wire. Many ISPs have built a test
> > > like this into their ISP-supplied CE routers (invoked using the TR-069
> > protocol and TR-181 data model) to test
> > > various stored key values. It has proven useful.
> >
> > I'm still confused. Are we talking about MACs or about certificates for DTLS?
> > I have no problems with text describing test for MAC keys. The text I'm
> > having problem with
> > is about testing certificates for DTLS. The test it describes is not clear for me:
> > it suggests to perform SHA2-256 hash of an input string "using the certificate
> > public key".
> > It is unclear for me how you would use the certificate public key to produce a
> > hash
> > of some input string. So I believe the test should be clarified.
> 
> Oops. Sorry. I totally mis-read your comment. Thanks for clarifying.

That's probably my fault, I should have be more clear from the very beginning.

> I see your point. That's pretty useless, as specified.
> The public and private parts of the key would really make something
> like this pretty complicated to actually use.
> I think I'd like to suggest just deleting babel-cert-test. Certificates aren't
> as finicky as MAC keys.

Another option would be to keep babel-cert-test, but redefine it 
to perform something useful. E.g. to test whether certificate
is not expired, not revoked and whether it's signature can be verified
using some trusted CA certificate.

But this is probably too complex for implementers and DTLS library checks certificates in any case,
so it's fine with me if you just delete babel-cert-test.

> > > > 3. Section 5 (Security Considerations):
> > > >
> > > > I think that text about keys (their length and properties) needs some
> > > > expansion. First, there are no any RFC2119 words discouraging using short
> > > > and
> > > > weak keys (there is some text, but without RFC2119 words and with no
> > > > references
> > > > it's just hand waving). Note, that draft-ietf-babel-hmac-12 has some text
> > > > about
> > > > the properties of the keys, so I believe at least it must be referenced
> > here. I
> > > > also suspect that explicitly allowing zero-length and short keys will lead to
> > > > situations when some network operators will use them (because they
> > are
> > > > not
> > > > prohibited), thus subverting security properties of MAC...
> > >
> > > Thanks. I'll add a reference to draft-ietf-babel-hmac Security
> > Considerations.
> > >
> > > Zero length and short keys were discussed on the mailing list. The group
> > considered it appropriate to
> > > allow configuration of zero-length keys for testing but to advise people to
> > follow best
> > > current practices. I find the use of normative language to attempt to
> > control the behavior of
> > > a home network owner (for example) or someone setting up an informal
> > ad hoc mesh
> > > network (for example) to be odd. IMO, the IETF should not seek to control
> > > the choices of people putting together such relatively small-scale networks
> > through
> > > the use of strong normative language in an information model
> > specification. It's
> > > impossible to enforce and such people pretty much never read RFCs.
> > >
> > > If there is a strong desire for some sort of normative language, then I could
> > suggest
> > > OLD
> > >    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.
> > > NEW
> > >    MAC keys are allowed to be as short as zero-length.  This is useful
> > >    for testing.  Network operators are RECOMMENDED 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. See the Security Considerations
> > >   section of [ID.draft-ietf-babel-hmac] for additional considerations
> > >   related to MAC keys.
> >
> > I would suggest additionally using "SHOULD NOT" for weak keys.
> > How about the following new text:
> >
> >     MAC keys are allowed to be as short as zero-length.  This is useful
> >     for testing.  Network operators are RECOMMENDED 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 and thus SHOULD NOT be used.
> >     See the Security Considerations section of [ID.draft-ietf-babel-hmac]
> >     for additional considerations related to MAC keys.
> >
> > (note that "SHOULD NOT" still allows people to shoot in their feet if they
> > want to).
> 
> OK. I'll make that change.

Thank you.

> > > > Nits.
> >
> > > > 4. Section 3.8:
> > > >
> > > >    babel-mac-key-use-sign:  Indicates whether this key value is used to
> > > >       sign sent Babel packets.  Sent packets are signed using this key
> > > >       if the value is "true".  If the value is "false", this key is not
> > > >       used to sign sent Babel packets.  An implementation MAY choose to
> > > >       expose this parameter as read-only ("ro").
> > > >
> > > > "Sign" is not a good word when you describe symmetric key operations
> > > > (which
> > > > computing MAC belongs to). Although it is often used informally, I think
> > that
> > > > RFC should be more meticulous in selecting words. I'd rather replace it
> > with
> > > > "compute MAC" and rename the entry to babel-mac-key-use-compute
> > or
> > > > babel-mac-key-use-mac (if it is possible). Note, that using "verify MAC" is
> > OK.
> > >
> > > I've been thinking through this. I can't speak to the informal nature of
> > "sign", but I can say that simply
> > > replacing "sign" with "compute" or "mac" wouldn't convey correctly what
> > this parameter is about. This
> > > parameter is primarily concerned with whether or not a MAC is included in
> > the sent packet. The sending is the
> > > critical piece, and not the computing (it's possible to compute the MAC
> > without sending it; a MAC in a sent
> > > packet is assumed to have been computed). I could change the description
> > to:
> > >        Indicates whether this key value is used to compute a MAC and include
> > that MAC in the
> > >        sent Babel packet.  A MAC for sent packets is computed using this key
> > >        if the value is "true".  If the value is "false", this key is not
> > >        used to compute a MAC to include in sent Babel packets.  An
> > implementation MAY choose to
> > >        expose this parameter as read-only ("ro")
> >
> > I'm fine with this.
> >
> > > But I struggle with the proposed parameter renaming. I strongly believe
> > the name should concisely describe
> > > that the Boolean value indicates whether or not to include a MAC in the
> > sent packet. The term "sign" is one
> > > I've commonly seen to indicate that a MAC is included in the sent packet.
> > I'm not aware of a different,
> > > similarly short word. "Compute" and "mac" do not convey the sending
> > aspect. And sending is very
> > > asymmetric.
> >
> > How about "use"?
> 
> Use has two problems in that it's already being used as part of babel-mac-key-use-verify,
> and that it really needs a word to go with it to indicate how it's used (like the -verify).
> Perhaps "send"? babel-mac-key-use-send ?

Great!

Regards,
Valery.

> > > > 5. Section 3.8:
> > > >
> > > >    babel-mac-key-value:
> > > >        ...
> > > >       This value is of a length suitable for the associated babel-mac-key-
> > > >       algorithm.  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 wonder of the rationale for imposing the above restrictions on HMAC
> > key
> > > > length. HMAC can use keys of any length, but if the key is greater than
> > block
> > > > size of underlying hash function, then it's first hashed (small performance
> > > > penalty). So I imagine that the rationale is to avoid this penalty. However,
> > as
> > > > RFC2104 states, key sizes greater than output length of the underlying
> > hash
> > > > function (32 bytes in case of SHA2-256) would not significantly increase
> > the
> > > > function strength, so it's just a waste of space. See also Issue 3 above.
> > >
> > > Juliusz said:
> > > > This was discussed at length on the mailing list.  It's not about
> > > > performance, it's about making it more difficult to use an unsafe
> > > > procedure for generating keys.
> > > >
> > > > Since Babel-MAC is vulnerable to dictionary attacks, the key must either
> > > > be drawn randomly or generated using a procedure that is hardened
> > against
> > > > such attacks (scrypt, etc.).  Applying the procedure described in RFC 2104
> > > > to a user-provided passphrase is not safe, and therefore we try to make
> > it
> > > > difficult for a naive user to do so.
> > > >
> > > > I am opposed to putting the RFC 2104 hashing procedure in the
> > information
> > > > model.  Doing so would be a disservice to our users.
> > >
> > > In addition to the rationale Juliusz mentioned, we (babel WG) also noted
> > that implementers
> > > of the babel MAC function were using existing libraries for the HMAC-
> > SHA256 algorithm.
> > > The user interface (UI) that accepted manual key entry was also from an
> > existing library. When
> > > the same longer strings were entered into different UIs of the different
> > implementations, these
> > > strings were treated differently and resulted in non-interoperability. The
> > "actual key" (using
> > > RFC 2104 words) ended up different. Requiring entered keys to be directly
> > usable as "actual
> > > keys" solved this problem. BTW, I have considered UIs for direct
> > management and configuration
> > > to effectively be implementations of the information model.
> > >
> > > I recommend no changes to this text.
> >
> > I can live with this if you add "SHOULD NOT" for zero-length keys in the
> > Security Consideration
> > (as I suggested above).
> 
> Agreed to the "SHOULD NOT". Thx.
> 
> > > > 8. Section 5 (Security Considerations):
> > > >
> > > >    MAC keys are allowed to be as short as zero-length.  This is useful
> > > >    for testing.
> > > >
> > > > I wonder what's benefit of allowing zero-length keys for testing
> > purposes.
> > > > What
> > > > is intended to be tested in this case? Implementation of MAC? Is it really
> > > > needed outside test lab? Am I missing something?
> > >
> > > As with the -test actions, this allows someone to diagnose whether a
> > problem they are having is with the
> > > formatting
> > > of the input key (hex, padded, ASCII, base64, etc.). This is by far one of the
> > most common problems when
> > > attempting to
> > > get different implementations to interoperate.
> >
> > OK, but I'd rather still add "SHOULD NOT" for using them as I suggested
> > above.
> 
> Agreed to the "SHOULD NOT". Thx.