Subject: [babel] Éric Vyncke's No Objection on draft-ietf-babel-hmac-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 00:57:04 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-babel-hmac-08: 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-hmac/

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

Thank you for the work put into this document. Using HMAC is usually simple but
this document builds a lot of negotiation around HMAC.

Regards,

-éric

== COMMENTS ==

I am a little puzzled by why HMAC keys/mechanisms are not identified to
facilitate the key rollover. The used mechanism appears a little heavy on the
required computing effort to compute several HMAC.

-- Section 1 --

The text about attacks on the Babel routing protocol should be better placed in
the security considerations of RFC7216bis.

== NITS ==

The DTLS document use the writing <"babel" port> while here it is <Babel port>.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 05 Aug 2019 18:19:41 +0200

> required computing effort to compute several HMAC.

This is a difficult tradeoff, and one that was extensively discussed on
the mailing list.

For any onlookers, the issue that Eric is referring to is that the HMAC
TLV only carries the HMAC: there is no key identifier, and there is no
indication of the HMAC algorithm used.  The receiving peer simply computes
its own HMAC of the packet with its configured (algo, key) pair(s), and
performs a bitwise comparison with the value(s) included by the sender.

This choice has a number of positive consequences:

 - the user interface is simplified (there's no key identifier) and hence
   the opportunity for human error is reduced (there's no opportunity
   for key identifier mismatches between routers);
 - the packet format is dramatically simplified, which is important for
   a security mechanism;
 - there is no need for yet another IANA registry for HMAC algorithms --
   a new algorithm can be deployed privately without involving a third party.

It also has one negative consequence:

 - during key rotation, HMAC must be computed twice, once for each
   configured key.

Since this protocol is not designed for carrying large numbers of keys,
and since HMAC computation is a reasonably cheap operation (and one that
is likely to be hardware-accelerated in production routers), it was felt
that the benefits of simplicity and protocol agility override the minor
computational cost.  For me, the overriding consideration is the
simplicity of the user interface -- a security mechanism will not get
deployed unless network administrators feel comfortable with it.

> the security considerations of RFC7216bis.

I'll think it over.

> The DTLS document use the writing <"babel" port> while here it is <Babel port>.

Right.  I'll fix that.

-- Juliusz