Re: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Roman, 

Stu prepared an updated version to address your review. The diff from previous version can be seen at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-17 

Can you please look at -17 and see if any further change is needed?

Thank you.  

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid [mailto:[e-mail]] De la part de Stuart W.
> Card
> Envoyé : jeudi 1 juillet 2021 09:44
> À : Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail]; tm-
> [e-mail]; BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>
> Objet : Re: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-reqs-
> 16: (with DISCUSS and COMMENT)
> 
> On 6/29/2021 5:31 PM, Roman Danyliw via Datatracker wrote:
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-drip-reqs-16: Discuss
> > ...
> > The document, along with other ballot positions, can be found
> here:
> > https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/
> > ...
> Roman et al --
> 
> Thanks again for the careful review. Rather than intersperse my
> responses in an email client direct quote of your message, for
> clarity, I exported it, trimmed it down, inserted my words,
> attributed your and my words explicitly to their respective authors,
> and then pasted it back in below.
> 
> 
> --------------------------------------------------------------------
> --
> DISCUSS:
> --------------------------------------------------------------------
> --
> 
> 
> ** Section 6.
> 
> <rd>
> Thanks for enumerating these highly desirable security properties as
> part of DRIP.  A bit more clarifying language is needed to explain
> which communication paths in the DRIP architecture (Figure 3 and 4)
> have these properties and under what circumstances.  Section 4.1 and
> 4.2 seem specific to properties between particular parties or
> messages. Likewise, subsequent text in this section such as “… there
> may be caveats on the extent to which requirements can be
> satisfied…” seems to suggest these are not universal across the
> architecture.
> </rd>
> 
> <swc>
> Right. I await the Document Shepherd's approval to upload my
> proposed revision 17, in which I have revised some of the text in
> Section 1.1 explaining Figure 1 (and correspondingly some text in
> Section 3.1 explaining Figure 3) as follows --
> 
>   Note the absence of any links to/from the UA in the figure; this
> is
>   because UAS RID and other connectivity involving the UA varies.
>   Some connectivity paths do or do not exist depending upon the
>   scenario. Command and Control (C2) from the GCS to the UA via the
>   Internet (e.g., using LTE cellular) is expected to become much
> more
>   common as Beyond Visual Line Of Sight (BVLOS) operations increase;
>   in such a case, there is typically not also a direct wireless link
>   between the GCS and UA. Conversely, if C2 is running over a direct
>   wireless link, then typically the GCS has but the UA lacks
> Internet
>   connectivity. Further, paths that nominally exist, such as between
>   an Observer device and the Internet, may be severely intermittent.
>   These connectivity constraints are likely to have an impact, e.g.,
>   on how reliably DRIP requirements can be satisfied.
> 
> With this caveat, our intention is to provide the desired
> properties, as specified by the numbered requirements in Section 4,
> wherever and whenever possible. With respect especially but not
> exclusively to Figure 4, GEN-1 and GEN-3 both explicitly demand
> "even on an Observer device lacking Internet connectivity at the
> time of observation."
> </swc>
> 
> 
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
> 
> 
> ** Abstract. "Complementing external technical standards as
> regulator-accepted means of compliance with UAS RID regulations..."
> 
> <rd>
> I had trouble parsing this sentence.  Is it saying that DRIP is a
> complementing way to comply with UAS RID regulations?  Have
> “regulators”
> confirmed that compliance with DRIP satisfies “UAS RID regulations”?
> </rd>
> 
> <swc>
> Regulators such as the FAA won't confirm anything about DRIP until
> we have published RFCs. However, FAA is collaborating with ASTM, and
> has expressed interest in DRIP solutions to some problems not being
> addressed by ASTM, especially how to issue single use Session IDs
> such that the FAA (only) can look up other information from them. I
> would prefer to keep the abstract very concise. Could this be
> addressed elsewhere in the document, if it needs to be addressed
> therein at all, rather than just in this email reply?
> </swc>
> 
> 
> ** Section 1.1.
> 
> <rd> Is there a reference for IEEE 802.11 Beacon modes? </rd>
> 
> <swc>
> IEEE 802.11 Beacon is a last minute addition to this draft, based on
> current ASTM work revising F3411 (which formerly required WiFi NAN)
> and recent EU standards actions. I stuck it in, without figuring out
> where, in the thousands of pages of IEEE 802.11 docs, I should cite
> something.
> Maybe someone more familiar with those could suggest a reference?
> </swc>
> 
> 
> ** Section 1.1.  Editorial.
> 
> <rd>
> s/to authorities; enable authorities/to authorities; and enable
> authorities/ </rd>
> 
> <swc>
> Thanks for catching this! The grammar checking software didn't.
> Arghh!
> Usually my grammar is pretty good. I will fix it.
> </swc>
> 
> 
> ** Section 4.1.1.  GEN-2 and GEN-3.
> 
> <rd>
> Since the name of the requirement is
> “provable binding” and “provable registration”, should the
> corresponding text convey the equivalently strong language.  For
> example:
> 
> GEN-2
> s/MUST enable binding all/MUST enable the cryptographic binding of
> all/
> 
> GEN-3
> s/MUST enable verification/MUST enable cryptographically-secure
> verification/ </rd>
> 
> <swc>
> I agree! I would be glad so to change the text of these two numbered
> requirements, if no one objects to my doing so?
> </swc>
> 
> 
> ** Section 4.1.1.
> 
> <rd>
> Per Gen-6, it would be helpful to more clearly state the pair wise
> communications that will be secured.
> </rd>
> 
> <swc>
> GEN-6 enumerates the endpoints _to which_ communications must be
> able to be established, but fails to specify any endpoints _from
> which_ they must be able to be initiated. This was intentional, as
> any party that obtains the UAS ID should be able to _request_ such
> establishment, yet only authorized parties ("with AAA") should be
> able to actually get it.
> So it is neither all nor only direct Observers. I would be glad to
> clarify this in 4.1.2 Rationale?
> </swc>
> 
> 
> ** Section 4.2.2.
> 
> <rd>
> Per “In Network RID, it would be used by the application running
> over HTTPS (and possibly other protocols)”, to be clear, is HTTPS a
> requirement?
> </rd>
> 
> <swc>
> ASTM F3411 specifies various HTTP methods for the interfaces among
> Network RID Service Providers (SP), Display Providers (DP) and the
> Discovery and Synchronization Service (DSS). It also specifies
> industry standard authentication and 128 bit or stronger encryption,
> but does not explicitly specify HTTPS, TLS or SSL. It implies but
> does not specify likewise for the DP to client interface. All
> implementations tested in FAA's UTM Pilot Project 2 used HTTPS. All
> this said as UAS RID context, HTTPS is not specifically a DRIP
> requirement. How much of this should be added to 4.2.2 Rationale?
> </swc>
> 
> 
> ** Section 4.3.1.
> 
> <rd>
> Is there a clear definition somewhere of
> (a) private information; and
> (b) safety critical information?
> </rd>
> 
> <swc>
> (a) Regulatory definitions vary by jurisdiction. In PRIV-1, DRIP
> defines private information very broadly as: "any and all
> information designated by neither cognizant authority nor the
> information owner as public". In the US, the FAA has specified that
> all the UAS RID information elements they require be broadcast for
> rule compliance are public and must be transmitted in cleartext.
> However, ASTM F3411 specifies the broadcast of additional
> information elements, not required by the FAA rule, which thus could
> be considered private (and eligible for encryption), if the UAS
> operator does not choose to disclose them publicly. Definition of
> private information is not really up to the DRIP WG, so however it
> may be defined in a given context, PRIV-4 states "DRIP SHOULD
> facilitate designation, by cognizant authorities and information
> owners, of which information is public and which is private". Also,
> we hope that a DRIP demonstration of effective means of maintaining
> operator privacy while ensuring that duly authorized parties can
> recover plaintext might encourage FAA and other regulators to allow
> selective encryption.
> 
> (b) Safety critical information in UAS RID is not defined explicitly
> anywhere to the best of the authors' knowledge. It is implied by the
> FAA rule that the pilot/GCS location is safety critical: but this
> likely is due to neither the FAA rule nor the ASTM F3411 standard
> making provision for an Observer to contact the pilot in any manner
> other than physically going to the pilot's location; whereas DRIP
> GEN-6 Contact requires this.
> EU regulations seem to imply that even the operator's identity is
> safety critical, but if a policeman could read from an auto license
> plate the name of the registered owner of the car, it is not
> apparent how that could help him prevent an auto accident. Again, it
> is hoped that a DRIP demonstration of how privacy, safety and
> accountability can all be accomodated may lead to relaxation of
> privacy unfriendly regulations.
> 
> How much of the above discussion merely needs to be archived as part
> of our IETF process, and how much needs to be added to 4.3.1
> Rationale?
> </swc>
> 
> 
> ** Section 4.3.1.  PRIV-2.
> 
> <rd>
> How would DRIP “know” that the local Observers are unlikely to be to
> be able to decrypt the information?
> </rd>
> 
> <swc>
> If the UAS is not participating in UTM, an Observer would have no
> means of obtaining a decryption key or decryption services from a
> cognizant USS. If the UAS is participating in UTM, but has lost
> connectivity with its USS, then an Observer within visual LOS of the
> UA is also unlikely to be able to communicate with that USS (whether
> due to the USS being offline or the UAS and Observer being in an
> area with poor Internet connectivity). Either of these conditions
> (UTM non-participation or USS
> unreachability) would be known to the UAS. The possibility always
> exists that the Observer has lost Internet access despite being near
> a UAS with such access, but the possibility of a policeman being
> unable to get a forced entry warrant quickly due to a flat tire on
> the way to see a judge does not justify prohibiting locks on house
> doors. ;-) Would providing these examples, in 4.3.2 Rationale, of
> how the UAS could reasonably assess that local Observers would be
> unlikely to be able to recover plaintext, suffice?
> </swc>
> 
> 
> ** Section 4.4.1.
> 
> <rd>
> REG-2 makes a point of enforcing AAA but REG-1 explicitly states
> “MUST NOT restrict access to this information based on identity or
> role of the party submitting the query”.  Would this normative MUST
> per REG-1 rule out denial of service mitigation (e.g., rate limited
> high volume queries from an IP address) or attempts to scrape the
> entire database?
> </rd>
> 
> <swc>
> The intent was to ensure that no member of the public would be
> hindered from accessing public information, while only duly
> authorized parties would be enabled to access private information.
> Mitigation of DoS and refusal to allow database scraping would be
> based on those behaviors, not on identity or role of the party
> submitting the query _per se_.
> These might be part of the information gathered on the misbehavior.
> Would adding this explanatory text to 4.4.2 Rationale suffice?
> </swc>
> 
> 
> ** Section 4.4.1.  REG-3.
> 
> <rd> What is “Internet direct contact information”? </rd>
> 
> <swc>
> A locator (e.g., IP address), or identifier (e.g., FQDN) that can be
> resolved to a locator, which would enable initiation of an end-to-
> end communication session using a well known protocol (e.g., SIP).
> Would adding this explanatory text to 4.4.2 Rationale suffice?
> </swc>
> 
> 
> --
> -----------------------------------------
> Stuart W. Card, PhD, Principal Engineer
> AX Enterprize, LLC  www.axenterprize.com
> 4947 Commercial Drive, Yorkville NY 13495
> 
> --
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.