Skip to main content

Early Review of draft-ietf-anima-constrained-voucher-11
review-ietf-anima-constrained-voucher-11-secdir-early-franke-2021-06-30-00

Request Review of draft-ietf-anima-constrained-voucher-10
Requested revision 10 (document currently at 24)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2021-06-30
Requested 2021-05-13
Requested by Toerless Eckert
Authors Michael Richardson , Peter Van der Stok , Panos Kampanakis , Esko Dijk
I-D last updated 2021-06-30
Completed reviews Iotdir Early review of -21 by Henk Birkholz (diff)
Genart Last Call review of -21 by Russ Housley (diff)
Yangdoctors Last Call review of -21 by Xufeng Liu (diff)
Secdir Early review of -23 by Kathleen Moriarty (diff)
Yangdoctors Early review of -00 by Carl Moberg (diff)
Secdir Early review of -11 by Daniel Fox Franke (diff)
Genart Early review of -10 by Russ Housley (diff)
Iotdir Early review of -12 by Henk Birkholz (diff)
Comments
This draft specifies a DTLS/CoAP based variation of BRSKI (RFC8995) which uses HTTPs instead. We think the text is mature enough such that early review would help to move the document forward faster. Multiple implementers are currently working on implementations and planning for interop testing at IETF111.

We suggest to reach out to the IESG reviewers of BRSKI/RFC8995 as they would be most familiar with the subject matter and review:

Jari Arkko (GEN)
Russ Housley (IOT)
Christian Huitema (ART)
Roman Danyliv (SEC)

(i'll be happy to ping those past reviewers as well, if that is the right process).
Assignment Reviewer Daniel Fox Franke
State Completed
Request Early review on draft-ietf-anima-constrained-voucher by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/JjzYESeYlkXat-GEu0N3NT9o4_A
Reviewed revision 11 (document currently at 24)
Result Not ready
Completed 2021-06-30
review-ietf-anima-constrained-voucher-11-secdir-early-franke-2021-06-30-00
I'm reviewing this document as a member of SecDir per the request for early
review.

I'm marking this as "Not Ready" principally because the whole Security
Considerations section is "TBD".

Having no prior familiarity with the ANIMA WG or its output, I found the
introductory section of this draft rather bewildering. The document I wanted to
read for background, RFC 8366, is cited a few sentences in, but the context
didn't make it clear that this was where I wanted to look. Please provide a
paragraph or so worth of background about the ecosystem that this draft lives
in before launching into protocol-specific jargon like "voucher" and "pledge".

You mention trying to conserve both network bandwidth and code size. I see how
you're saving a bit of bandwidth by shortening URLs, using CBOR instead of
JSON, and in some cases avoiding retransmission of public keys. But I'm not
following where the code size wins come from. The procedure described in
section 5.3.1 doesn't seem to save anything significant, since you still need a
whole RFC 5280 implementation for the fallback path.

You've given "ECDSA" as a mandatory-to-implement algorithm, but haven't
specified what particular curves must be supported. Without this, you haven't
gotten any closer to assuring interoperability.

Appendix A looks like a funny thing to find in an RFC. Are you planning to have
the RFC Editor remove this prior to publication, like you'd do for an
"Implementation Status" section? If so, you should include an explicit
instruction to that effect.