Matt, Thanks for your quick and detailed review. Some comments in line. -25 will be out in the next 24-hours making corrections based on your comments.
Your comments on the use of Wrapper and Manifest are being fixed throughout the document and have been snipped from this reply. -------- 73, Adam T. Wiethuechter Software Engineer; AX Enterprize, LLC ________________________________ From: Matt Joras via Datatracker <nore...@ietf.org> Sent: Wednesday, October 12, 2022 4:28 PM To: gen-art@ietf.org <gen-art@ietf.org> Cc: draft-ietf-drip-auth....@ietf.org <draft-ietf-drip-auth....@ietf.org>; tm-...@ietf.org <tm-...@ietf.org> Subject: Genart early review of draft-ietf-drip-auth-24 Reviewer: Matt Joras Review result: Ready with Nits Below is some pseudo-inline review of this document for gen-art. Without authentication, an Observer has no basis for trust. As the messages are sent via wireless broadcast, they may be transmitted anywhere within wireless range and making any claims desired by the sender. Observer has not yet been defined here, is it expected that the reader knows what this refers to? <atw> Defined in RFC9153, which should be pre-requisite reading but how exactly do we enforce that? I never followed that rule in school. :-) Perhaps if I add a bit more to Section 2.2 like this: > This document makes use of the terms defined in > [RFC9153<https://www.ietf.org/archive/id/draft-ietf-drip-auth-24.html#RFC9153>]. to > This document makes use of the terms (such as Observer, USS, UTM, etc.) > defined in > [RFC9153<https://www.ietf.org/archive/id/draft-ietf-drip-auth-24.html#RFC9153>]. </atw> DRIP Specific Authentication Methods, carried in ASTM Authentication Messages (Message Type 0x2) are defined herein. These methods, when properly used, enable a high level of trust in that the content of other ASTM Messages was generated by their claimed registered source. The last sentence here is a bit confusing, consider rewording "enable a high level of trust in that the". <atw> Looks like it was a bad copy paste during a recent reworking of that paragraph. Switched to: "enable a high level of trust in the content of other ASTM Messages that was generated by their claimed registered source" </atw> Extended Transports: use of extended advertisements (Bluetooth 5.x), service info (Wi- Fi NaN) or vendor specific element information (Wi-Fi BEACON) in broadcast frames as specified in [F3411]. Must use ASTM Message Pack (Message Type 0xF). Is Wi-Fi NaN supposed to be Wi-Fi NAN? <atw> Yes, good catch. </atw> HHIT Domain Authority (HDA): A class of DIME usually associated with a USS in UTM. Is it expected that the reader know what DIME, USS, and UTM are? <atw> RFC9153 strikes again. I will expand these out on first use however regardless. </atw> [F3411] defines Authentication Message framing only. It does not define authentication formats or methods. It explicitly anticipates several signature options, but does not fully define even those. [F3411] Annex A1 defines a Broadcast Authentication Verifier Service, which has a heavy reliance on Observer real-time connectivity to the Internet (specifically into UTM) that is not always guaranteed. Fortunately, [F3411] also allows third party standard Authentication Types, several of which DRIP defines herein. "but does not fully define even those." -> "but does not fully define those." "which has a heavy reliance on Observer real-time connectivity to the Internet (specifically into UTM) that is not always guaranteed." -> "which has a heaby reliance on an Observer's real-time connectivity to the Internet" <atw> Both changes will be taken. The second sentence change may have some contension with my co-author who may want to emphasize the link to UTM. We shall see how it plays out. </atw> 3.1.4. UAS RID Trust Section 3.1.1, Section 3.1.2 and Section 3.1.3 above complete the trust chain but the chain cannot yet be trusted as having any relevance to the observed UA because reply attacks are trivial. At this point the key nominally possessed by the UA is trusted but the UA has not yet been proven to possess that private key. Should "reply" be "replay"? Also, I'm not sure what "cannot yet be trusted as having any relevance to the observed UA" means. <atw> "replay" is correct. Thanks for the catch. I am not sure how to address your second point. Perhaps @Stu Card<mailto:stu.c...@axenterprize.com> can help here and come up with some better text? </atw> 4.3.1. Message Count When decoding a DRIP Wrapper on a receiver, the number of messages wrapped can be determined by checking the length between the UA DET and the VNB Timestamp by UA is a multiple of 25-bytes. Consider rewording. "checking" here sort of implies that an invariant is being checked, rather than the number of messages being calculated (i.e. integral division by 25). <atw> Rewording "checking" to "calculating". </atw> [...] "concatenated together into a single byte object" is a bit confusing -- does this imply mixing the hashes into a single byte or literally concatenating the bytes to form a byte sequence? <atw> I was having a hard time find the correct words, but your second statement is correct. It is a concatenated byte sequence. Rewording: > concatenated together into a single byte object to > concatenated together to form a contiguous byte sequence </atw> [...] 9.1. Replay Attacks The astute reader may note that the DRIP Link messages, which are recommended to be sent, are static in nature and contain various timestamps. These DRIP Link messages can easily be replayed by an attacker who has copied them from previous broadcasts. If an attacker (who is smart and spoofs more than just the UAS ID/ data payloads) willing replays an DRIP Link message they have in principle actually helped by ensuring the message is sent more frequently and be received by potential Observers. "astute" and "smart" are not required here, I would recommend sticking to being factual. Additionally, "willing replays an DRIP Link message they have in principle actually helped by ensuring the message is sent more frequently and be received by potential Observers." is a confusing sentence, and I do not know what it means exactly. <atw> What the sentence means is that because the DRIP Link is static and if an attacker replays it; they have indirectly helped by sending the DRIP Link more often to Observers. @Stu Card<mailto:stu.c...@axenterprize.com>, do you think this needs to be worded better? </atw>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
