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

From: "Stuart W. Card" <[email-masked]>
Date: Thu, 1 Jul 2021 03:44:14 -0400

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

---

From: <[email-masked]>
Date: Thu, 8 Jul 2021 05:28:12 +0000

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:[email-masked]] De la part de Stuart W.
> Card
> Envoyé : jeudi 1 juillet 2021 09:44
> À : Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked]; tm-
> [email-masked]; BOUCADAIR Mohamed INNOV/NET
> <[email-masked]>
> Objet : Re: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-reqs-
> 16: (with DISCUSS and COMMENT)
> 
> 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.
> 
> 
> 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 --
> 
> 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>
> 
> 
> 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.
> 
> 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.
> s/to authorities; enable authorities/to authorities; and enable
> authorities/ </rd>
> 
> <swc>
> “provable binding” and “provable registration”, should the
> corresponding text convey the equivalently strong language.  For
> example:
> 
> GEN-2
> verification/ </rd>
> 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.
> 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>
> 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>
> (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.
> 
> 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>
> 
> 
> 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>
> “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_.
> resolved to a locator, which would enable initiation of an end-to-
> end communication session using a well known protocol (e.g., SIP).
> Tm-rid mailing list
> [email-masked]
> 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.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 23 Jul 2021 20:39:03 +0000

Hi Stu!

Focusing on the DISCUSS only, please see inline ...

> -----Original Message-----
> From: Stuart W. Card <[email-masked]>
> Sent: Thursday, July 1, 2021 3:44 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS
> and COMMENT)
> 
> 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.
> 
> 
> Thanks for enumerating these highly desirable security properties as part of
> DRIP.  A bit more clarifying language is needed to explain which
> 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>
> 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 --
> 
> 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>

Thanks for the revised -17 and the additional specificity it provides.  I'm still having difficulty reconciling what in fact is mandatory and which security properties DRIP is mandating.

(a) Section 4.1 and 4.2 makes normative (MUST-level ) requirements about security properties.  No concerns with these firm requirements.

(b) Section 6 appears to summarize these requirements into general principles.  Certainly more precise could be applied, but that's not my primary concern.

Despite these stated requirements, there is text that appears to caveat the mandatory nature of the "MUST"/"must" used in Sections 4.1, 4.2 and 6.   For example:

(c) Section 1.1. "These connectivity constraints are likely to have an impact, e.g., on how reliably DRIP requirements can be satisfied."

(d) Section 6. "Thus there may be caveats on the extent to which requirements can be satisfied in such cases, yet strenuous effort should be made to satisfy them, as such cases, e.g., firefighting in
   a national forest, are important."

The flexibility of (c) and (d) makes sense.  However, as a matter of consistency, if (c) and (d) are true, then the "MUSTs" in (a) and (b) are in fact "SHOULDs" because there are anticipated cases where these requirements are will not or cannot be satisfied (and that's intentional).

Put into narrative form:

-- In Section 6:

OLD:
It may be inferred from the general requirements (Section 4.1) for
   provable ownership, provable binding, and provable registration,
   together with the identifier requirements (Section 4.2), that DRIP
   must provide:

<list of properties>

NEW

It may be inferred from the general requirements (Section 4.1) for
   provable ownership, provable binding, and provable registration,
   together with the identifier requirements (Section 4.2), that DRIP
   aspires to provide:

<list of properties>

Particular use cases, operational conditions or deployment architecture patterns may prevent these security properties from being present.

-- Certain requirements of Section 4.* are ) s/MUST/SHOULD/

Regards,
Roman

> ** 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”
> 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.
> 
> 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.
> “provable binding” and “provable registration”, should the corresponding text
> convey the equivalently strong language.  For example:
> 
> GEN-2
> s/MUST enable verification/MUST enable cryptographically-secure verification/
> </rd>
> 
> <swc>
> 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>
> (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
> 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
> 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>
> 
> 
> 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
> 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_.
> 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>
> 
> 
> --

---

From: "Card, Stu" <[email-masked]>
Date: Fri, 23 Jul 2021 17:49:58 -0400

Roman et al --

What we mean is:

1) In any connectivity scenario where it is possible to satisfy the MUST
requirements, they are indeed MUST requirements on the DRIP protocols
themselves.

2) Scenarios will often arise where lower layer connectivity does not
support the DRIP protocols fully accomplishing our goals. TCP does not
provide reliable in-order stream delivery in cases where the only link goes
down before the connection can be started, or goes down and stays down
after connection establishment; TCP MUST requirements are not relaxed to
SHOULD just because of this. DRIP is no different.

We merely highlight that UAS connectivity is highly variable, so DRIP
protocols should (lower case) be designed with this in mind: to meet the
requirements at all times & in all places where it would be possible for
any protocol in those layers on those nodes to do so; and to be robust to
the vagaries intrinsic to the environment.

I am very comfortable revising Section 6.

I am very uncomfortable weakening the numbered requirements, as that would
let implementors off the hook for things that really are MUST for the DRIP
protocols (when underlying connectivity permits). Also changing numbered
requirements is not something I as editor really should do without
concurrence of the DRIP WG, whose prior consensus was that these were MUST.

I am very open to text changes that clarify the intent without absolving
implementors of meeting it.

Thanks for your consideration of all this.

On Fri, Jul 23, 2021, 16:39 Roman Danyliw <[email-masked]> wrote:

> responses in an
> part of
> specific to
> explaining
> Thanks for the revised -17 and the additional specificity it provides.
> I'm still having difficulty reconciling what in fact is mandatory and which
> security properties DRIP is mandating.
>
> (a) Section 4.1 and 4.2 makes normative (MUST-level ) requirements about
> security properties.  No concerns with these firm requirements.
>
> (b) Section 6 appears to summarize these requirements into general
> principles.  Certainly more precise could be applied, but that's not my
> primary concern.
>
> Despite these stated requirements, there is text that appears to caveat
> the mandatory nature of the "MUST"/"must" used in Sections 4.1, 4.2 and 6.
>  For example:
>
> (c) Section 1.1. "These connectivity constraints are likely to have an
> impact, e.g., on how reliably DRIP requirements can be satisfied."
>
> (d) Section 6. "Thus there may be caveats on the extent to which
> requirements can be satisfied in such cases, yet strenuous effort should be
> made to satisfy them, as such cases, e.g., firefighting in
> The flexibility of (c) and (d) makes sense.  However, as a matter of
> consistency, if (c) and (d) are true, then the "MUSTs" in (a) and (b) are
> in fact "SHOULDs" because there are anticipated cases where these
> requirements are will not or cannot be satisfied (and that's intentional).
>
> Put into narrative form:
>
> -- In Section 6:
>
> OLD:
> Particular use cases, operational conditions or deployment architecture
> patterns may prevent these security properties from being present.
>
> complementing
> have
> current
> authorities/
> text
> must be
> HTTPS
> Network
> private
> encourage
> anywhere to
> critical,
> our
> of
> that
> from
> resolved to a

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 26 Jul 2021 12:53:55 -0400

Roman --

If you are available to join our DRIP session this Wednesday, you would be
most welcome, as your DISCUSS is one of three pressing issues we currently
have, and I do not wish to misrepresent your position. Thanks!

-- Stu

On Fri, Jul 23, 2021 at 5:49 PM Card, Stu <[email-masked]> wrote:

>> as specified
>> corresponding text
>> this said
>> defines private
>> owners, of
>> safety critical,
>> exists that

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 28 Jul 2021 12:23:23 +0000

Hi Stu!

Sure.  I’m double booked during the DRIP meeting session today, but can step out and join the WG if there is a more precise time window.  When would be a good time (inside the Session II time window?

Roman

From: Card, Stu <[email-masked]>
Sent: Monday, July 26, 2021 12:54 PM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; [email-masked]; Eric Vyncke (evyncke) <[email-masked]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

Roman --

If you are available to join our DRIP session this Wednesday, you would be most welcome, as your DISCUSS is one of three pressing issues we currently have, and I do not wish to misrepresent your position. Thanks!

-- Stu

On Fri, Jul 23, 2021 at 5:49 PM Card, Stu <[email-masked]<mailto:[email-masked]>> wrote:
Roman et al --

What we mean is:

1) In any connectivity scenario where it is possible to satisfy the MUST requirements, they are indeed MUST requirements on the DRIP protocols themselves.

2) Scenarios will often arise where lower layer connectivity does not support the DRIP protocols fully accomplishing our goals. TCP does not provide reliable in-order stream delivery in cases where the only link goes down before the connection can be started, or goes down and stays down after connection establishment; TCP MUST requirements are not relaxed to SHOULD just because of this. DRIP is no different.

We merely highlight that UAS connectivity is highly variable, so DRIP protocols should (lower case) be designed with this in mind: to meet the requirements at all times & in all places where it would be possible for any protocol in those layers on those nodes to do so; and to be robust to the vagaries intrinsic to the environment.

I am very uncomfortable weakening the numbered requirements, as that would let implementors off the hook for things that really are MUST for the DRIP protocols (when underlying connectivity permits). Also changing numbered requirements is not something I as editor really should do without concurrence of the DRIP WG, whose prior consensus was that these were MUST.

I am very open to text changes that clarify the intent without absolving implementors of meeting it.

On Fri, Jul 23, 2021, 16:39 Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stu!

> From: Stuart W. Card <[email-masked]<mailto:[email-masked]>>
> To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>

Put into narrative form:

-- In Section 6:

OLD:

<list of properties>

NEW

<list of properties>

Regards,
Roman

> AX Enterprize, LLC  www.axenterprize.com<http://www.axenterprize.com>

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 28 Jul 2021 07:52:30 -0500

Roman --

I must defer to our WG chairs on agenda, but considering the importance of
getting our requirements published (to guide our solution efforts & give
ASTM, ICAO et al a doc to cite), I would think we would accomodate your
joining us whenever you can take a few minutes to express your critical
concerns with the draft. Thanks.

-- Stu

On Wed, Jul 28, 2021, 07:23 Roman Danyliw <[email-masked]> wrote:

> Hi Stu!
>
>
>
> Sure.  I’m double booked during the DRIP meeting session today, but can
> step out and join the WG if there is a more precise time window.  When
> would be a good time (inside the Session II time window?
>
>
>
> Roman
>
>
>
> *From:* Card, Stu <[email-masked]>
> *Sent:* Monday, July 26, 2021 12:54 PM
> *To:* Roman Danyliw <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Eric Vyncke
> (evyncke) <[email-masked]>
> *Subject:* Re: Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with
> DISCUSS and COMMENT)
>
>
>
> Roman --
>
>
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 28 Jul 2021 15:10:51 +0000

Romand and Stu

As I am obviously participating to the DRIP WG meeting and have a ‘private’ channel with Roman, then I will ping Roman when drip-reqs is discussed and if Roman is available, then I am sure that he will join :-)

Thank you all for being SO cooperative: the IETF spirit !

-éric

From: Tm-rid <[email-masked]> on behalf of "Card, Stu" <[email-masked]>
Date: Wednesday, 28 July 2021 at 14:53
To: Roman Danyliw <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Vyncke <[email-masked]>
Subject: Re: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

Roman --

I must defer to our WG chairs on agenda, but considering the importance of getting our requirements published (to guide our solution efforts & give ASTM, ICAO et al a doc to cite), I would think we would accomodate your joining us whenever you can take a few minutes to express your critical concerns with the draft. Thanks.

-- Stu

On Wed, Jul 28, 2021, 07:23 Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stu!

Roman

From: Card, Stu <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 26, 2021 12:54 PM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

Roman --

-- Stu

What we mean is:

Put into narrative form:

-- In Section 6:

OLD:

<list of properties>

NEW

<list of properties>

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 28 Jul 2021 21:13:17 +0000

Hi Stu!

From: Card, Stu <[email-masked]>
Sent: Friday, July 23, 2021 5:50 PM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

Roman et al --

What we mean is:

[Roman] To use language from system engineering, it all depends on the system boundary.  In the case of TCP, a broken link wouldn’t invalidate the requirement that TCP must provide reliable in-order stream delivery, as the lower layer connectivity is outside of the scope of the guarantee.  By my read, the current requirements text sets no boundaries what elements of the DRIP architecture are in scope for the security guarantees enumerated in Section 4.* leaving a default of “all of it” (or the entire end-to-end scope).  Therefore, having text that caveats that these MUST-level guarantees are in fact aspirational depending on the specific implementation creates a conflict.

Regards,
Roman

  Additionally, it isn’t clear what parts of the DRIP architecture

Put into narrative form:

-- In Section 6:

OLD:

<list of properties>

NEW

<list of properties>

Regards,
Roman