Valery --
Thanks for the review! As you have already seen from the preliminary responses, we are collectively working on addressing all your points. Here, I would like to address just one, from a different perspective. So below I will snip your mail down to just that one point.
We included, in the Security Considerations section, the idea of a large malicious UA carrying a small and seemingly harmless UA as a false flag. We did not put this idea in there because we felt that mitigating such vulnerabilities was in scope of IETF. We put it there to forestall some of the discussion that would otherwise ensue about protecting private keys that could be used for spoofing. As a device (small UA) containing a private key can be physically carried by another device (large UA), there is no way clever key distribution/management/protection can prevent one device spoofing generally as another such readily available device. This is quite distinct from preventing a device from spoofing as a _specific_ other device: with DRIP, Carol's UA cannot successfully pretend to be Bob's UA.
Your review suggests, to me, that we should make the above reasoning explicit in the draft.
On Wed, Mar 30, 2022 at 9:51 AM Valery Smyslov via Datatracker <noreply@xxxxxxxx> wrote:
...
5. While an example when one UA physically steals UAS RID sender of another UA
is clever, I think that such scenarios (physical security) are not in scope of
IETF work. I believe that many others similar schemes can be invented, so I
suggest to discuss physical security in a separate subsection of Section 9.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
