|
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 >
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
