[Emu] Éric Vyncke's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-emu-eap-noob-04: 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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



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

Thank you for the work put into this document. I really like the ideas behind
this OOB authentication.

Please find below some non-blocking COMMENT points (**but replies would be
appreciated esp around CBOR**), and some nits.

Special thanks to Dave Thaler for his early IoT directorate review (and the
CBOR discussion with Carsten):
https://datatracker.ietf.org/doc/review-ietf-emu-eap-noob-01-iotdir-early-thaler-2020-06-12/
https://mailarchive.ietf.org/arch/msg/iot-directorate/PNi6nxtR7_1T2rxu7O49HRx5Kdg/

I hope that this helps to improve the document,

Regards,

-éric

PS: when the ballot for this document was created, I failed to spot the DNS &
IoT aspects of it, hence, the absence of INT and IoT directorates telechat
reviews.

== COMMENTS ==

Like Carsten, I am really puzzled by the lack of consideration of CBOR to
replace JSON especially for a protocol aimed at constrained devices. Was this
discussed at the WG level ? I was unable to read any discussion on the mail
list except about the IoT directorate thread.

This non-obvious choice of encoding ***should really be discussed*** in the
document.

-- Section 2 --
Please apply the current BCP 14 template and not the old RFC 2119 one.

-- Section 3.1 --
"timeout needs to be several minutes rather than seconds" can this lead to a
DoS against the server, which potentially needs to keep states for minutes ?

-- Section 3.2.1 --
I am not a EAP expert, so bear with my possibly naive question, "based on the
realm part of the NAI", isn't it always "eap-noob.arpa" in this case ?

-- Section 3.2.2 --
What happens if the peer does not support any of the server's ciphersuite? Esp
in the world of IoT where peers are old and cannot always be updated.Should
there be a forward pointer to section 3.6.4 ?

-- Section 3.2.3 --
Suggest to give a hint to the reader for "Hoob": is this Hash of OoB ? Same
comment for "Noob".

== NITS ==

Global nit: I prefer the use of 'octet' rather than 'byte'.

-- Section 1 --
Please avoid the use of 'we' as in 'We thus do not support'.