Re: [Iot-directorate] Iotdir last call review of draft-ietf-drip-arch-22

[Thomas Fossati <[e-mail]>]

Hi Stuart,

> Thanks for the review! I was asked to address one of your nits,

Thank you!

> all of your other points having been addressed previously by others
> (we think/hope).

I haven't seen any reply from your co-authors and, unless I missed it,
there was no publicly visible updates to the draft version that I
reviewed (-22), so I cannot confirm nor deny :-)

> "Bluetooth 4.x" and "Bluetooth 5.x" are intended to distinguish
> between those two major versions, which have differences motivating
> different Broadcast RID message encapsulation, but imply concisely
> that Broadcast RID is insensitive to the minor versions.

Sure.

> ASTM F3411 requires that if a Broadcast RID sender uses any form of
> Bluetooth, it must use 4.x, with additional use of 5.x being optional.
> The corresponding ASD-STAN for Direct RID states the reverse. Thus
> effectively any implementation intended for international use must
> concurrently transmit over both 4.x and 5.x.

!

> The Bluetooth specs are voluminous: attempting to cite all those that
> apply here would be quite a rabbit hole; I personally would prefer to
> cite only ASTM F3411 and let the diligent student follow the reference
> trail.

Sounds reasonable..

> Will our editing the draft to consistently use the forms "4.x" and
> "5.x" suffice?

Yes.

Cheers, t


> On 3/27/2022 1:44 PM, Thomas Fossati via Datatracker wrote:
> > Reviewer: Thomas Fossati
> > Review result: Ready with Issues
> >
> > This is a great document and fun to read.  Thank you authors!  I
> > have tried to highlight a few small things that could be articulated
> > a bit more from an IoT perspective but overall I have no major
> > concerns with it, except a tangential thing around the document
> > intended status (see "Issues" below.)
> >
> > # Issues
> >
> > * The charter says: "the WG will propose a standard document that
> > describes the architecture […]" but the status is informational.  I
> > am pretty sure informational should be appropriate, but highlighting
> > a potential disconnect.
> >
> > # Comments
> >
> > * In some IETF circles (e.g., RATS & TEEP) "attestation" has a
> > precise meaning, which is quite distinct from the DRIP definition
> > "[…] normally used when an entity asserts a relationship with
> > another entity".  Specifically, unless the signing key is derived
> > from the measured boot state (a la DICE), or the claims are of a
> > certain kind, the process that this doc names "attestation" is not
> > what is meant usually.
> >     => Maybe add a few words to Section 2.2 to clarify the
> >     distinction between DRIP attestation and RATS's, e.g., by adding
> >     a disclaimer similar to that already associated with DRIP certs.
> >
> > * Apropos "remote attestation", I am wondering whether, given the
> > type of endpoints considered in the architecture - and in particular
> > provided their increased exposure to physical compromise, and the
> > potentially large impact on the overall system and beyond - the
> > architecture should provide explicit channels for securely conveying
> > the verification of the installed and booted firmware (as well as
> > any other relevant trust metrics)?
> >
> > * I haven't read the rest of the DRIP docs, so I am not sure why is
> > EdDSA specifically mentioned in Section 3.2.?  Is this a requirement
> > or just an example?  I guess the latter, but checking just in case.
> > And apropos that, in light of fault attacks on deterministic ECDSA
> > and EdDSA [0] that are potentially easier to carry out against UAs
> > (BTW, how cool is a fault attack w/ private key exfiltration carried
> > out by a chasing drone?) maybe it's worth adding to the security
> > considerations some words around physical attacks and their impact
> > on the choice of signature algorithms?
> >
> > * It'd seem that, given the very low bandwidth, DoS (as well as
> > Denial of View) attacks on communication involving the UA should be
> > quite easy to mount?  Maybe worth spending some words on the
> > argument to describe what the threats are and which mitigations are
> > available.
> >
> > * This is a question more than anything else: given the constrained
> > nature of UAs, I was wondering whether it is envisaged that the
> > end-to-end network path will be realised with the use of more
> > capable (trusted) proxy nodes?  If so, there may be a few security
> > and privacy considerations to be added.
> >
> > # Nits
> >
> > * AAA is usually intended as "Authentication, Authorization, and
> > Accounting" (see also [1]), whereas here it's got four new A's:
> > Attestation, Access Control , Attribution, Audit :-)
> >      => Maybe change it to 7A, A7, AAA+ or similar?
> >
> > * In Section 2.1, the following terms are already in the most recent
> > "RFC Editor Abbreviations List" [1] and can be removed:
> >      * EdDSA
> >      * HIP
> >      * HIT
> >      * HI
> >
> > * Some typographic inconsistency around Bluetooth: Is it 4 or 4.x?
> > 5 or 5.x?
> >      => Stick to one format. (Also maybe add an explicit reference
> >      to the Bluetooth specs.)
> >
> > [0] https://eprint.iacr.org/2020/803
> > [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt
> >
> >
> >
> --
> -----------------------------------------
> Stuart W. Card, PhD, Principal Engineer
> AX Enterprize, LLC  www.axenterprize.com
> 4947 Commercial Drive, Yorkville NY 13495
> 592 Hangar Road, Rome NY 13441
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.