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?
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".
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?
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?
[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"
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.
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).
The functionality of Wrapper in this form is identical to Message Set
Signature (Authentication Type 0x3) when running over Extended
Transports. What Wrapper provides is the same format but over both
Extended and Legacy Transports allowing the transports to be similar.
Message Set Signature also implies using the ASTM validator system
architecture which relies on Internet connectivity for verification
which the receiver may not have at the time of receipt of an
Authentication Message. This is something Wrapper, and all DRIP
Authentication Formats, avoid when the UA key is obtained via a DRIP
Link Authentication Message.
"Wrapper" without an article (the) reads a bit strangely, and in the subsequent
paragraph "the Wrapper format" is used instead.
The primary limitation of the Wrapper format is the bounding of up to
4 ASTM Messages that can be sent within it. Another limitation is
that the format can not be used as a surrogate for messages it is
wrapping. This is due to high potential a receiver on the ground
does not support DRIP. Thus, when Wrapper is being used the wrapper
data must effectively be sent twice, once as a single framed message
(as specified in [F3411]) and then again wrapped within the Wrapper
format.
As above, some inconsistency with "Wrapper" and "wrapper" and "the Wrapper
format".
By hashing previously sent messages and signing them we gain trust in
a UA's previous reports without retransmitting them. An Observer who
has been listening for any length of time SHOULD hash received
messages and cross-check them against the manifest hashes. This is a
way to evade the limitation of a maximum of 4 messages in the Wrapper
Format (Section 4.3.3) and greatly reduce overhead.
As above, "the Wrapper Format" is now used, inconsistent with above.
Judicious use of Manifest enables an entire Broadcast RID message
stream to be strongly authenticated with less than 100% overhead
relative to a completely unauthenticated message stream (see
Appendix E).
Similar to comment on "Wrapper", "Judicious use of Manifest" without a leading
article (i.e. "the Manifest") reads awkwardly.
The evidence section of the DES (Section 4.1.2) is populated with
8-byte hashes of [F3411] Broadcast RID messages and two special
hashes (Section 4.4.2). All these hashes can be concatenated
together into a single byte object or be set in the evidence section
individually. The Previous Manifest Hash and Current Manifest Hash
MUST always come before the ASTM Message Hashes as seen in Figure 8.
"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?
A receiver SHOULD use the manifest to verify each ASTM Message hashed
therein that it has previously received. It can do this without
having received them all. A manifest SHOULD typically encompass a
single transmission cycle of messages being sent, see Section 6.4 and
Appendix E.
Is manifest not "Manifest" here? If so, the distinction is not completely clear.
The number of hashes in the Manifest can be variable (2-11). An easy
way to determine the number of hashes is to take the length of the
data between the end of the UA DET and VNB Timestamp by UA and divide
it by the hash length (8). If this value is not an integer, the
message is invalid.
As above with "Manifest". Also, "If this value is not an integer," seems
imprecise. Integer division by most definitions only results in integers. I
assume what was intended is that length of the data must be integer-divisible
by the hash length.
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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
