Subject: [babel] Erik Kline's No Objection on draft-ietf-babel-hmac-10: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Mon, 17 Aug 2020 01:22:54 -0700

Erik Kline has entered the following ballot position for
draft-ietf-babel-hmac-10: 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:
----------------------------------------------------------------------

[[ comments ]]

[ section 4.3 ]

* s/worthwile/worthwhile/

[ section 5 ]

* Is another option for implementations to be in a mode where:

    - they send authenticated packets
    - they attempt to authenticate packets received
    - if a packet does not authenticate is it still accepted
    - if a packet does authenticate then the neighbor entry is updated
      to note that all future communications with that neighbor must be
      use authentication (and any unauthenticated packets from this neighbor
      are dropped and maybe logged)?

[ section 7 ]

* s/an administators/an administrator's/, I think

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2020 12:01:59 +0200

> * s/worthwile/worthwhile/

Done, thanks.

> * Is another option for implementations to be in a mode where:

  [snipped]

It's certainly a good idea, but it's not described in this document.
First, we haven't implemented it, and as a principle the Babel working
group refrains from standardising features that don't have at least one
implementation (this has been broken on a few occasions, notably due to
the insistence of some IESG members, but it remains a principle we try to
stick to).  Second, the document tries to accurately describe the security
properties that have been proven to hold; I haven't given it a lot of
thought, but it could conceivably take some work to formulate the security
properties of the subprotocol that you suggest and to prove that they hold.

While I don't think the document should be delayed any further, I think it
would be a good idea to write up, implement and prove the correctness of
the subprotocol that you suggest.  Should you wish to do so, I'd be glad to
collaborate with you.

> * s/an administators/an administrator's/, I think

Done, thanks.  I'll submit a new revision ASAP.

-- Juliusz