Stu here, chiming in, primarily on those specific issues where Adam
called me out. My comments are interspersed below and I have trimmed out
any areas on which I have none.
On 10/13/2022 3:06 PM, Adam Wiethuechter wrote:
*From:* Matt Joras via Datatracker <[email protected]>
Reviewer: Matt Joras
Review result: Ready with Nits
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>
Actually, we want to make clear that we are not encouraging trust in the
message content itself, only authenticating that the content indeed came
from the claimed source.
E.g. "enable a high level of trust in that the" => "enable a high level
of trust that the"
Simple removing the word "in" from the original sentence should fix it?
[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."
I originally wrote that sentence so am to blame. I was attempting to
draw a distinction between ASTM's explicitly and intentionally declining
to specify auth formats or methods, and their listing but not fully
specifying signature options. As it reads, it may seem I was casting
aspersions. Perhaps we can reword in some manner that does not cast
aspersions but retains the distinction?
"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>
The parenthetical notation was intended only to point out that this
lookup is dependent upon UTM systems, so they constitute an additional
point of potential failure. However, the primary issue, from which we do
not want to distract the reader, is that the Observer may not have
viable Internet connectivity at the place and time of observing the UA,
and thus with the on-line authentication service, would not be able to
authenticate received Broadcast RID messages.
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.
... Also, I'm not sure what "cannot yet be trusted as
having any relevance to the observed UA" means.
<atw>
...
I am not sure how to address your second point. Perhaps @Stu Card
<mailto:[email protected]> can help here and come up with some
better text?
</atw>ua
Trust that a key is valid and registered is not proof that a given party
owns/possesses that key. A sender (typically UA) can broadcast the
entire chain of links from root to leaf of a key that sender does not
actually have. Only when the UA signs, using that leaf key, some content
that is not easily guessed and clearly pertains to the observed UA, does
the Observer have any reason to believe that and the other information
signed with that same key pertain to that UA. We can submit this to our
technical writer here to try to develop alternative text to "cannot yet
be trusted as having any relevance to the observed UA" to try to make
that clear?
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>
We have conflated 2 issues here.
(1) We want to sanity check that the Wrapper is of a valid length, which
must be a multiple of 25; if not, something is wrong and we probably
want to discard the message and complain.
(2) We need to know how many messages are in the Wrapper. We can
calculate that by dividing the length by 25.
So, this could be pseudo-coded as:
wrapperLengthValid := ((wrapperLength MOD 25) == 0);
wrappedMsgCount := wrapperLength DIV 25;
So we are _both_ "checking" and "calculating". ;-)
Wording to be smithed.
[...]
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:[email protected]>, do you think this needs to be
worded better?
</atw>
This relates to my comment above on 3.1.4 UAS RID Trust. A would-be
replay attacker retransmitting DRIP Link messages does not accomplish a
replay attack. Indeed, such retransmission increases the likelihood that
any given Observer receives all the links of the chain needed to
establish trust in the _key_ which is distinct from the sender's
_possession_ of said key. Again we can give this to our hard-working
tech writer Laura (and that isn't even really her job but she is good at
it).
--
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLCwww.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495
592 Hangar Road, Rome NY 13441
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
