Re: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt

[shuai zhao <[e-mail]>]

Hi Eric,

Thanks for your comments.

The text of Sec 4, 5 and 6 are actually not completely new. We just re-organized previous text into specific topics:
section 4: introduce HHIT
section 5: introduce DRIP registration and registry
Section 6: introduce Crowd-sourced RID. 

The above concepts (HHIT/Registry/registration/CS-RID) were in the arch- since -00 WG draft . 

If the concern is too much normative text in those sections, we can trim down the specification details and use informative language. 

Best,
Shuai



> On Feb 15, 2021, at 11:54 AM, Eric Vyncke (evyncke) <[e-mail]> wrote:
> 
> Shuai and others,
>  
> Sorry for belated reply... 
>  
> I just had a quick browse through the document and I am afraid that section 4, 5, and 6 are normative (they specify what to do) and it is really unusual in an architecture document (but there are exceptions). Moreover, it uses the normative BCP14 uppercase words “MUST”, “SHOULD”, etc. that should only apply in a normative “protocol action” document and would also require a BCP 14 template.
>  
> AFAIK, the HHIT part was added recently but it was done a little too fast. These sections should be about architecture and not about specifications or does the DRIP WG really want to have specifications in an architecture document ?
>  
> Sorry for not spotting this before: nothing negative about the architecture itself but more about following the right process to ease the publication process ;-)
>  
> Regards
>  
> -éric
>  
>  
> From: Tm-rid <[e-mail] <mailto:[e-mail]>> on behalf of Daniel Migault <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, 5 January 2021 at 00:01
> To: shuai zhao <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt
>  
> Hi Shuai, 
>  
> Happy new year 2021!. 
>  
> I have shortly reviewed the current version. I believe the document is heading in the right direction, but I believe interactions between the elements ( in a DRIP context) could be described in a simpler and easiest way. The way I see an architecture document is mostly exposing which boxes are involved and which box talks to which box. This includes the purpose of the communication as well as the protocol being used. I think a high level description could well fit in the architecture overview. The complex part is that here there are at least two main use cases, and many boxes - some more active than the others.
> Currently we do have some additional description around  RID, and the registries. I believe that is appropriated but I believe these sections could be clarified and simplified.
> I have included below some comments I had while reading the document - I hope this input will be helpful!
>  
> Yours, 
> Daniel    
>  
> 
>         Drone Remote Identification Protocol (DRIP) Architecture
>                         draft-ietf-drip-arch-07
> 
> [...]
> 
> 1.  Introduction
> 
>    This document describes a natural Internet and MAC-layer broadcast-
>    based architecture for Unmanned Aircraft System Remote Identification
>    and tracking (UAS RID), conforming to proposed regulations and
>    external technical standards, satisfying the requirements listed in
>    the companion requirements document [I-D.ietf-drip-reqs].
> 
> <mglt>
> It is unclear to me the reason, if there is
> any, to have "natural" being mentioned. I
> think the idea is to mention that there is
> the possibility that the UAS communicate
> directly to the provider using IP
> communications - which sounds natural.  As L2
> and L3 communications are happening at
> different layers, it also seems to me that
> saying "Internet and MAC-layer" might not
> clearly indicate there are two communications
> that are envisioned. So maybe that could be
> emphasized. 
> 
> I am not having a strong opinion on how to
> handle these comments. My main purpose is to
> avoid to have the reader being sent off
> track. I have the impression we could mention
> the UAS needs to enable different
> communications depending on its use case. 
> 
> I think that the purpose of the architecture
> description is not necessarily to match the
> requirements. It seems to me the document is
> mostly describing the entity involved. I
> think here, given that the requirement
> document has a huge description of the use
> cases, we can state we assume the reader is
> familiar with that document for the
> description of the use cases.  The idea here
> would be to tell the reader "the architecture
> document may not be the one you should start
> with" maybe have a look at the requirements
> for the use cases. 
> 
> </mglt>
> 
>    Many considerations (especially safety) dictate that UAS be remotely
>    identifiable.  Civil Aviation Authorities (CAAs) worldwide are
>    mandating Unmanned Aircraft Systems (UAS) Remote Identification
>    (RID).  CAAs currently (2020) promulgate performance-based
>    regulations that do not specify techniques, but rather cite industry
>    consensus technical standards as acceptable means of compliance.
> 
> [...]
> 
> 1.2.1.  Network RID
> 
>    A RID data dictionary and data flow for Network RID are defined in
>    [F3411-19].  This data flow is from a UAS via unspecified means (but
>    at least in part over the Internet) to a Network Remote ID Service
>    Provider (Net-RID SP).  These Net-RID SPs provide this information to
> <mglt>
> I believe that "this information" refers to
> the data. If so I am wondering if using the
> same terminology may be clearer. I also
> expect that the information refers to the
> data being processed, so eventually, we may
> clarify what this information is.
> 
> </mglt>
>    Network Remote ID Display Providers (Net-RID DP).  It is the Net-RID
>    DP that respond to queries from Network Remote ID clients (expected
> 
> <mglt>
> I am wondering if the client are not here
> designated or represented on the figure as
> Observers. If so, we may clarify this. Note
> that I think keeping client is fine, but we
> may simply mention that  in the context of
> the figure it is being represented as an
> Observer. 
> 
> </mglt>
>    typically, but not specified exclusively, to be web based) specifying
>    airspace volumes of interest.  Network RID depends upon connectivity,
>    in several segments, via the Internet, from the UAS to the observer.
> 
>    The Network RID is illustrated in Figure 1 below:
> 
>                x x  UA
>                xxxxx       ********************
>                 |   \    *                ------*---+------------+
>                 |    \   *              /       *  | NET_RID_SP |
>                 |     \  * ------------/    +---*--+------------+
>                 | RF   \ */                 |   *
>                 |        *      INTERNET    |   *  +------------+
>                 |       /*                  +---*--| NET_RID_DP |
>                 |      / *                  +---*--+------------+
>                 +     /   *                 |   *
>                  x   /     *****************|***      x
>                xxxxx                        |       xxxxx
>                  x                          +-------  x
>                  x                                    x
>                 x x   Operator (GCS)      Observer   x x
>                x   x                                x   x
> 
>                                   Figure 1
> 
>    Via the direct Radio Frequency (RF) link between the UA and GCS,
>    Command and Control (C2) flows between the GCS to the UA such that
>    either can communicate with the Net-RID SP.  For all but the simplest
>    hobby aircraft, position and status flow from the UA to the GCS and
>    on to the Net-RID SP.  Thus via the Internet, through three distinct
>    segments, Network RID information flows from the UAS to the Observer.
> 
> <mglt>
> If correct, it might be worth mentioning that
> the RF communication is not part of the RID
> architecture.  
> 
> </mglt>
> 
> 
> 
> 
> 
> 
> 
> 
> Card, et al.               Expires 3 July 2021                  [Page 4]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
> 1.2.2.  Broadcast RID
> 
>    A set of RID messages are defined for direct, one-way, broadcast
>    transmissions from the UA over Bluetooth or Wi-Fi.  These are
>    currently defined as MAC-Layer messages.  Internet (or other Wide
>    Area Network) connectivity is only needed for UAS registry
>    information lookup by Observers using the locally directly received
>    UAS RID as a key.  Broadcast RID should be functionally usable in
>    situations with no Internet connectivity.
> 
> <mglt>
> Though I understand that Broadcast RID do not
> require Internet connectivity.  I also have
> the impression that this interface will be
> always on - even if there is internet
> connectivity and a reliable communication to
> the display provider.  The reason is - to me
> - that the display provider can only provide
> information that has been received from a
> service provider. I can imagine a UAS not
> providing its information to a SP and being
> in the range of other UAS. If such situation
> may happen, Broadcast is the backup
> communication and probably closer to what is
> happening on the ground. Of course a UAS not
> broadcasting is another case and needs to be
> "detected". I am wondering if that makes
> sense, and it should probably be detailed in
> the security consideration section.   
> 
> </mglt>
> 
>    The Broadcast RID is illustrated in Figure 2 below.
> 
>                   x x  UA
>                  xxxxx
>                    |
>                    |
>                    |     app messages directly over
>                    |     one-way RF data link (no IP)
>                    |
>                    |
>                    +
>                    x
>                  xxxxx
>                    x
>                    x
>                    x x   Observer's device (e.g. smartphone)
>                  x   x
> 
>                                   Figure 2
> 
>    With Broadcast RID, an Observer is limited to their radio "visible"
>    airspace for UAS awareness and information.  With Internet queries
>    using harvested RID, the Observer may gain more information about
>    those visible UAS.
> 
> [...]
> 
> 1.4.  Overview of DRIP Architecture
> 
>    The requirements document [I-D.ietf-drip-reqs] also provides an
>    extended introduction to the problem space, use cases, etc.  Only a
>    brief summary of that introduction will be restated here as context,
>    with reference to the general architecture shown in Figure 4 below.
> 
> 
> 
> <mglt>
> There is always the question whether
> something should be repeated or referenced. I
> think it makes sense here to repeat. 
> 
> </mglt>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Card, et al.               Expires 3 July 2021                  [Page 6]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
>          General      x                           x     Public
>          Public     xxxxx                       xxxxx   Safety
>          Observer     x                           x     Observer
>                       x                           x
>                      x x ---------+  +---------- x x
>                     x   x         |  |          x   x
>                                   |  |
>             UA1 x x               |  |  +------------ x x UA2
>                xxxxx              |  |  |            xxxxx
>                   |               +  +  +              |
>                   |            xxxxxxxxxx              |
>                   |           x          x             |
>                   +----------+x Internet x+------------+
>        UA1        |           x          x             |       UA1
>       Pilot     x |            xxxxxxxxxx              | x    Pilot
>      Operator  xxxxx              + + +                xxxxx Operator
>       GCS1      x                 | | |                  x    GCS2
>                 x                 | | |                  x
>                x x                | | |                 x x
>               x   x               | | |                x   x
>                                   | | |
>                 +----------+      | | |       +----------+
>                 |          |------+ | +-------|          |
>                 | Public   |        |         | Private  |
>                 | Registry |     +-----+      | Registry |
>                 |          |     | DNS |      |          |
>                 +----------+     +-----+      +----------+
> 
>                                   Figure 4
> 
>    Editor's note 1: the architecture may need more clarification, and
>    address the following:
> 
>    *  connectivity requirements among UA, GCS, SP, DP (if necessary)
> 
>    DRIP will enable leveraging existing Internet resources (standard
>    protocols, services, infrastructure and business models) to meet UAS
>    RID and closely related needs.  DRIP will specify how to apply IETF
>    standards, complementing [F3411-19] and other external standards, to
>    satisfy UAS RID requirements.  DRIP will update existing and develop
>    new protocol standards as needed to accomplish the foregoing.
> 
>    This document will outline the UAS RID architecture into which DRIP
>    must fit, and an architecture for DRIP itself.  This includes
>    presenting the gaps between the CAAs' Concepts of Operations and
>    [F3411-19] as it relates to use of Internet technologies and UA
>    direct RF communications.  Issues include, but are not limited to:
> 
> <mglt>
> To me the complex part is that DRIP defines
> an identifier, some frames to communicate
> that RID over L2 as well as session
> establishment protocols for internet
> connectivity, DNS update protocols,....  I
> tend to agree that one may have to point on
> each interface what the focus of the DRIP
> architecture is. But maybe there will be a
> more straight forward way to do.  
> 
> I think that this section should provide a
> high level description on how each element
> works between each other as well as their
> relation to DRIP.  
> 
> This section should also clarify: 
> how the UAS interact with the various
> registries, USS. This includes the protocol
> being used as well as the expected
> provisioning and authentication. Does RID is
> even used between the UAS and USS ?  
> 
> how the observer observe the RID and proceed
> to the request to the various registries.
> 
> Currently it seems to me the document is
> mostly describing RID and interactions with
> the registries. I think we need more to
> provide a comprehensive architecture
> document. 
> 
> If the represented DNS does not contain any
> DRIP information, and is only used for
> standard DNS resolution, then, it seems not
> necessary. 
> 
> 
> 
> </mglt>
> 
> 
> Card, et al.               Expires 3 July 2021                  [Page 7]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
>    *  Mechanisms to leverage Domain Name System (DNS: [RFC1034]) and
>       Extensible Provisioning Protocol (EPP [RFC5731]) technology to
>       provide for private (Section 5.2) and public (Section 5.1)
>       Information Registry.
> 
>    *  Trustworthy Remote ID and trust in RID messages (Section 4)
> 
>    *  Privacy in RID messages (PII protection) (Section 8)
> 
>       Editor's Note 2 : The following aspects are not covered in this
>       draft, yet.  We may consider add sections for each of them if
>       necessary.
> 
>    *  UA -> Ground communications including Broadcast RID
> 
>    *  Broadcast RID 'harvesting' and secure forwarding into the UTM
> 
>    *  Secure UAS -> Net-RID SP communications
> 
>    *  Secure Observer -> Pilot communications
> 
> [...]
> 
> 3.3.  Claims, Assertions, Attestations, and Certificates
> 
>    This section introduces the meaning of "Claims", "Assertions",
>    "Attestations", and "Certificates" in the context of DRIP.
> 
>    This is due, in part, to the term "certificate" having significant
>    technologic and legal baggage associated with it, specifically around
>    X.509 certificates.  These type of certificates and Public Key
>    Infrastructure invokes more legal and public policy considerations
>    than probably any other electronic communication sector.  It emerged
>    as a governmental platform for trusted identity management and was
>    pursued in intergovernmental bodies with links into treaty
>    instruments.  As such the following terms are being used in DRIP.
> 
> <mglt>
> I believe this section should mention the
> rats architecture document and align to its
> definitions. I have the impression we
> slightly differ from their definitions and
> would like as much as possible to avoid
> having our owned definitions. 
> 
> https://www.ietf.org/archive/id/draft-ietf-rats-architecture-08.html#name-artifacts <https://www.ietf.org/archive/id/draft-ietf-rats-architecture-08.html#name-artifacts>
> </mglt>
> 
>    Claims:
> 
>       For DRIP claims are used in the form of a predicate (X is Y, X has
>       property Y, and most importantly X owns Y).  The basic form of a
>       claim is an entity using a HHIT as an identifier in the DRIP UAS
>       system.
> 
>    Assertions:
> 
>       Assertions, under DRIP, are defined as being a set of one or more
>       claims.  This definition is borrowed from JWT/CWT.  An HHIT in of
>       itself can be seen as a set of assertions.  First that the
> 
> 
> 
> Card, et al.               Expires 3 July 2021                  [Page 9]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
>       identifier is a handle to an asymmetric keypair owned by the
>       entity and that it also is part of the given registry (specified
>       by the HID).
> 
>    Attestations:
> 
>       An attestation is a signed claim.  The signee may be the claimant
>       themselves or a third party.  Under DRIP this is normally used
>       when a set of entities asserts a relationship between them along
>       with other information.
> 
>    Certificates:
> 
>       Certificates in DRIP have a narrow definition of being signed
>       exclusively by a third party and are only over identities.
> 
> 4.  HHIT for UAS Remote ID
> 
>    This section describes the basic requirements of a DRIP UAS remote ID
>    per regulation constrains from ASTM [F3411-19] and explains the use
>    of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6
>    addresses and thereby a trustable Identifier for use as the UAS
>    Remote ID.  HHITs self-attest to the included explicit hierarchy that
>    provides Registrar discovery for 3rd-party ID attestation.
> 
> 4.1.  UAS Remote Identifiers Problem Space
> 
>    A DRIP UAS ID needs to be "Trustworthy".  This means that within the
>    framework of the RID messages, an observer can establish that the RID
>    used does uniquely belong to the UA.  That the only way for any other
>    UA to assert this RID would be to steal something from within the UA.
> 
> <mglt>
> As in some cases I have the impression the
> RID is owned by the GCS. I have the
> impression UA should be the UAS. I would
> maybe avoid to have the sentence That the
> only way for other... but that is a personal
> suggestion, so please feel free to do what
> you believe is best to do.  
> 
> </mglt>
> 
>    The RID is self-generated by the UAS (either UA or GCS) and
>    registered with the USS.
> 
> <mglt>
> I am wondering if that will be always the
> case, and if manufacturer or user will not at
> some point provision the UAS. It seems to me
> safer to consider his description assumes or
> consider the RID will be self generated.   
> 
> Having read further down I think the document
> contradict itself as both scenario are being
> envisioned. 
> </mglt>
> 
>    Within the limitations of Broadcast RID, this is extremely
>    challenging as:
> 
>    *  An RID can at most be 20 characters.
> 
>    *  The ASTM Basic RID message (the message containing the RID) is 25
>       characters; only 3 characters are currently unused.
> 
>    *  The ASTM Authentication message, with some changes from [F3411-19]
>       can carry 224 bytes of payload.
> 
> <mglt>
> It is unclear to me what is the relation
> between the first and second item and believe
> that it should be clarified.  I have the
> impression that - if correct - the following
> may be clearer to the reader. The
> communication of the RID to be trustworthy
> needs to be associated with some
> authentication. The ASTM defines the Basic
> RID message that is expected to contained the
> RID and the Authentication message that is
> expected to contain the necessary
> authentication information. The Basic RID
> message has a maximum payload of 25 bytes and
> the maximum size allocated by ASTM for the
> RID is 20 bytes - as 3 bytes are left unused.
> The authentication maximum payload is defined
> to be 224 bytes.    
> 
> </mglt>
> 
>    Standard approaches like X.509 and PKI will not fit these
>    constraints, even using the new EdDSA [RFC8032] algorithm. 
> 
> <mglt>
> If the document mentions that X.509 is not
> possible, I believe that more details should
> be provided. I do not know the minimum X509
> certificate but EdDSA keys are 32 (57) bytes,
> and signatures are 64 (114) bytes.  This
> seems to long for the RID to use the key
> directly, but on the other hand public_key
> and signature could be 32+64 = 98
> (57+114=171) bytes which could fit in 224.
> As there are also some other work on
> certificate for IoT, I would rather not say
> this is not possible and instead mention that
> HIT is an example that address this.  To me,
> but I might be wrong, it seems that the main
> driver for HIT is that we could use the RID
> to establish session between the RID owner
> and some other parties. 
> 
> </mglt>
> 
> An
>    example of a technology that will fit within these limitations is an
> 
> 
> 
> Card, et al.               Expires 3 July 2021                 [Page 10]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
>    enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401]
>    introducing hierarchy as defined in HHIT [I-D.ietf-drip-rid]; using
>    Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID
>    [I-D.ietf-drip-rid].  As PKI with X.509 is being used in other
>    systems with which UAS RID must interoperate (e.g. the UTM Discovery
>    and Synchronization Service and the UTM InterUSS protocol) mappings
>    between the more flexible but larger X.509 certificates and the HHIT
>    based structures must be devised.
> 
>    By using the EdDSA HHIT suite, self-assertions of the RID can be done
>    in as little as 84 bytes.  
> 
> <mglt>
> I think that only apply with Ed25519, that is
> 20 + 64 with a spacial relation between the
> RID and the public key. If so it might be
> worth specifying that the example considers a
> specific use case here Ed25519.   
> 
> I believe also that a short description of
> the HHIT may be clarifying.  
> 
> </mglt>
> 
> Third-party assertions can be done in 200
>    bytes.  An observer would need Internet access to validate a self-
>    assertion claim.  A third-party assertion can be validated via a
>    small credential cache in a disconnected environment.  This third-
>    party assertion is possible when the third-party also uses HHITs for
>    its identity and the UA has the public key for that HHIT
> 
> 4.2.  HIT as A Trustworthy UAS Remote ID
> 
>    For a Remote ID to be trustworthy in the Broadcast mode, there MUST
>    be an asymmetric keypair for proof of ID ownership.  The common
>    method of using a key signing operation to assert ownership of an ID,
>    does not guarantee name uniqueness.  Any entity can sign an ID,
>    claiming ownership.  To mitigate spoofing risks, the ID needs to be
>    cryptographically generated from the public key, in such a manner
>    that it is statistically hard for an entity to create a public key
>    that would generate (spoof) the ID.  Thus the signing of such an ID
>    becomes an attestation (compared to claim) of ownership.
> 
> <mglt>
> I think the evidence is composed of 2 claims,
> the RID and the signature.  The attestation
> seems to be the process of retrieving the
> public key and checking the key, rid and
> signature.  That said I am not entirely sure
> I got it right either. 
> 
> </mglt>
> 
>    HITs are statistically unique through the cryptographic hash feature
>    of second-preimage resistance.  The cryptographically-bound addition
>    of the Hierarchy and a HHIT registration process (e.g. based on
>    Extensible Provisioning Protocol, [RFC5730]) provide complete, global
>    HHIT uniqueness.  This is in contrast to general IDs (e.g. a UUID or
>    device serial number) as the subject in an X.509 certificate.
> 
> 4.3.  HHIT for Remote ID Registration and Lookup
> 
>    Remote IDs need a deterministic lookup mechanism that rapidly
>    provides actionable information about the identified UA.  The ID
>    itself needs to be the key into the lookup given the constraints
> 
> <mglt>
> It might be clearer here to replace key by
> input as to make sure the key mentioned has
> no cryptographic properties. 
> 
> </mglt>
> 
>    imposed by some of the broadcast media.  This can best be achieved by
>    an ID registration hierarchy cryptographically embedded within the
>    ID.
> 
> 
> 
> 
> 
> 
> 
> Card, et al.               Expires 3 July 2021                 [Page 11]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
>    The original proposal for HITs included a registration hierarchy
>    scheme.  This was dropped during HIP development for lack of a use
>    case.  No similar mechanism is possible within CGAs.  It is a rather
>    straightforward design update to HITs to Hierarchical HITs (HHITs) to
>    meet the UAS Remote ID use case.
> 
> <mglt>
> It is not so clear to me why CGA is mentioned
> here. I do not see this as necessary - unless
> I am missing something. 
> 
> </mglt>
> 
>    The HHIT needs to consist of a registration hierarchy, the hashing
>    crypto suite information, and the hash of these items along with the
>    underlying public key.  Additional information, e.g. an IPv6 prefix,
>    may enhance the HHITs use beyond the basic Remote ID function (e.g.
>    use in HIP, [RFC7401]).
> 
> <mglt>
> The paragraph above does not appear to me
> very clear. The term "registration hierarchy"
> may require some additional explanation. I
> have the impression that it lists the
> information that may be associated/registered
> to the RID. If that is correct, I believe
> this may be clearly stated.  We may also
> clearly state what are the mandatory
> information, at least the public key and the
> nature of the RID - HHIT here.
> 
> </mglt>
> 
>    A DRIP UAS ID SHOULD be a HHIT.  
> 
> <mglt>
> It seems to me that this is one assumption of
> this document. That said, I have the
> impression the DRIP itself is simply used as
> an input to retrieve some information so the
> nature of the RID - in our case that it is
> HHIT must be provided. It seems to me an
> information as important as the public key. 
> 
> </mglt>
> 
>   It SHOULD be self-generated by the
>    UAS (either UA or GCS) 
> 
> <mglt>
> I believe that the RID is not itself
> self-generated, but instead the keys. I am
> not entirely convinced this is the right
> place for having the information. Typically,
> I am wondering how this would help impact the
> registration or lookup based on the RID. I
> think this is an important recommendation
> though.  Maybe section 4.2 is more
> appropriated for such comment. 
> 
> </mglt>
> 
> and MUST be registered with the Private
>    Information Registry identified in its hierarchy fields.  Each UAS ID
>    HHIT MUST NOT be used more than once, with one exception as follows.
> 
> <mglt>
> Maybe the Private Information Registry needs
> to be better defined. I might have missed it,
> but so far it seems that is the first time it
> has been introduced in the document. More
> specifically, I would expect that a clear
> distinction between what is private and
> public is made.  
> 
> I also have the impression that the
> architecture should enable a HHIT to be
> updated for every flight, but I am not sure
> that is something that is necessarily
> mandatory. I think a MUST NOT statement is
> here a bit too strong. Probably such
> statement is more privacy consideration
> statement. Similarly to my previous
> statement, I have the impression that this
> consideration is a bit out of scope of the
> lookup section. I am wondering if having a
> HHIT for RID section ( without lookup,
> encryption,... ) should not be part of
> section 4.2.   
> 
> </mglt>
> 
>    Each UA MAY be assigned, by its manufacturer, a single HI and derived
>    HHIT encoded as a hardware serial number per [CTA2063A].  Such a
>    static HHIT SHOULD be used only to bind one-time use UAS IDs (other
>    HHITs) to the unique UA. 
> 
> <mglt>
> It seems this section can be simplified. It
> seems the text exposes how a UA provisioned
> with one "static* or long term key can
> generate ephemeral RIDs. I do not find
> necessary to introduce HI for a long term
> private key. In addition, HHIT derived from
> that key do not seem to be the RID an
> observer can observe, as only one-time RIDs
> are used. As a result, it seems confusing to
> me to use HHIT for long term secrets.  I am
> wondering if the text is willing to say that
> ephemeral HHIT (not based on the long term
> public key) are redirected to the long term
> RID or if any salt mechanism is used to
> enable to generate multiple HHIT from one
> public key.  I think the mechanism should be
> further described, but it seems to me that
> this is a mechanisms that could also be
> reserved to the privacy consideration
> section. In fact it may not deeply affect the
> architecture itself as opposed to use the
> architecture in place to provide privacy.
> </mglt>
> 
>    Depending upon implementation, this may
>    leave a HI private key in the possession of the manufacturer (see
>    Security Considerations).
> 
>    Each UA equipped for Broadcast RID MUST be provisioned not only with
>    its HHIT but also with the HI public key from which the HHIT was
>    derived and the corresponding private key, to enable message
>    signature.  Each UAS equipped for Network RID MUST be provisioned
>    likewise; the private key SHOULD reside only in the ultimate source
>    of Network RID messages (i.e. on the UA itself if the GCS is merely
>    relaying rather than sourcing Network RID messages).  Each observer
>    device MUST be provisioned with public keys of the UAS RID root
>    registries and MAY be provisioned with public keys or certificates
>    for subordinate registries.
> 
>    Operators and Private Information Registries MUST possess and other
>    UTM entities MAY possess UAS ID style HHITs.  When present, such
>    HHITs SHOULD be used with HIP to strongly mutually authenticate and
>    optionally encrypt communications.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Card, et al.               Expires 3 July 2021                 [Page 12]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
> 4.4.  HHIT for Remote ID Encryption
> 
>    The only (at time of Trustworthy Remote ID design) extant fixed
>    length ID cryptographically derived from a public key are the Host
>    Identity Tag [RFC7401], HITs, and Cryptographically Generated
>    Addresses [RFC3972], CGAs.  Both lack a registration/retrieval
>    capability and CGAs have only a limited crypto agility [RFC4982].
>    Distributed Hash Tables have been tried for HITs [RFC6537]; this is
>    really not workable for a globally deployed UAS Remote ID scheme.
> 
>    The security of HHITs is achieved first through the cryptographic
>    hashing function of the above information, along with a registration
>    process to mitigate the probability of a hash collision (first
>    registered, first allowed).
> 
> <mglt>
> I am not convinced this section is needed. 
> </mglt>
> 
> 5.  DRIP HHIT RID Registration and Registries
> 
>    The DRIP HHIT RID registration goes beyond what is currently
>    envisioned in UTM for the UAS to USS registration/subscription
>    process.
> 
>    UAS registries hold both public and private UAS information resulting
>    from the UAS RID registration.  Given these different uses, and to
>    improve scalability, security and simplicity of administration, the
>    public and private information can be stored in different registries,
>    indeed different types of registry.
> 
> 5.1.  Public Information Registry
> 
> [...]
> 
> 5.1.2.  Proposed Approach
> 
>    A DRIP public information registry MUST respond to standard DNS
> <mglt>
> It does not look to me appropriated to use
> MUST. The architecture defines public
> information being host in DNS seems to me
> sufficient. It might be worth specifying if
> DNSSEC is expected to be supported or not. 
> 
> I do not also believe that having a proposed
> approach is appropriated. It suggests that
> the DRIP architecture has other alternatives.
> I would simply describe what the DRIP
> architecture considers.
> </mglt>
> 
> queries, in the definitive public Internet DNS hierarchy.
> 
> It MUST
>    support NS, MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per
>    [RFC8005]) types. 
> 
> <mglt>
> It seems this goes a bit too far into the
> specification. I do not see listing the
> RRtypes being supported as necessary to be
> mentioned in an architecture document. I also
> question the relation to DRIP of NS or MX
> RRtypes. 
> 
> </mglt>
> 
> If a DRIP public information registry lists, in a
>    HIP RR, any HIP RVS servers for a given DRIP UAS ID, those RVS
>    servers MUST restrict relay services per AAA policy; this may require
>    extensions to [RFC8004].  These public information registries SHOULD
>    use secure DNS transport (e.g.  DNS over TLS) to deliver public
>    information that is not inherently trustable (e.g. everything other
>    than attestations).
> 
> <mglt>
> If DNS over TLS is used, this also means that
> the DNS infrastructure - resolvers cannot be
> used. I potentially this this causing some
> issues when no connectivity is provided. I
> suspect that DNSSEC may be more appropriated
> to re-use the DNS architecture and ease
> adaptation to off line use cases.  
> 
> </mglt>
> 
> 5.2.  Private Information Registry
> 
> 5.2.1.  Background
> 
>    The private information required for DRIP RID is similar to that
>    required for Internet domain name registration.  This information
>    SHOULD be available for ALL UAS, including those that only use
>    Network RID. 
> <mglt>
> I think it might worth clarifying how an
> information accessible to ALL UAS is private. 
> 
> </mglt>
> 
> A DRIP RID solution can leverage existing Internet
>    resources: registration protocols, infrastructure and business
>    models, by fitting into an ID structure compatible with DNS names.
>    This implies some sort of hierarchy, for scalability, and management
>    of this hierarchy.  It is expected that the private registry function
>    will be provided by the same organizations that run USS, and likely
>    integrated with USS.
> 
> 5.2.2.  Proposed Approach
> 
>    A DRIP RID MUST be amenable to handling as an Internet domain name
>    (at an arbitrary level in the hierarchy), MUST be registered in at
>    least a pseudo-domain (e.g. .ip6.arpa for reverse lookup), and MAY be
>    registered as a sub-domain (for forward lookup).  This DNS
>    information MAY be protected with DNSSEC.  Its access SHOULD be
>    protected with a secure DNS transport (e.g.  DNS over TLS).
> 
> <mglt>
> It may not be very clear to me if private
> informations are expected to be hosted. If
> so, TLS might be mandatory and we me also
> clarify how this information is expected to
> remained cached in resolvers for example. 
> 
> </mglt>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Card, et al.               Expires 3 July 2021                 [Page 14]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
>    A DRIP private information registry MUST support essential Internet
>    domain name registry operations (e.g. add, delete, update, query)
>    using interoperable open standard protocols.  It SHOULD support the
>    Extensible Provisioning Protocol (EPP) and the Registry Data Access
>    Protocol (RDAP) with access controls.  It MAY use XACML to specify
>    those access controls.  It MUST be listed in a DNS: that DNS MAY be
>    private; but absent any compelling reasons for use of private DNS,
>    SHOULD be the definitive public Internet DNS hierarchy. 
> 
> <mglt>
> I am not convinced that specifying the format
> for access rules are necessary here, nor EPP.
> It is unclear to me at that stage if the
> registry is a DNS server or something else. I
> have the impression the text should express
> better the function of the Public and Private
> registries.     
> 
> </mglt>
> 
> The DRIP
>    private information registry in which a given UAS is registered MUST
>    be findable, starting from the UAS ID, using the methods specified in
>    [RFC7484].  A DRIP private information registry MAY support WebFinger
>    as specified in [RFC7033].
> 
> [...]
> 
> 8.  Privacy for Broadcast PII
> 
>    Broadcast RID messages may contain PII.  This may be information
>    about the UA such as its destination or Operator information such as
>    GCS location.  There is no absolute "right" in hiding PII, as there
>    will be times (e.g., disasters) and places (buffer zones around
>    airports and sensitive facilities) where policy may mandate all
>    information be sent as cleartext.
> <mglt>
> I do not believe cleartext is recommendable
> in any way as it is subject to spoofing. The
> minimum must be authenticated-only. 
> 
> </mglt>
> 
> Otherwise, the modern general
>    position (consistent with, e.g., the EU General Data Protection
>    Regulation) is to hide PII unless otherwise instructed.  While some
>    have argued that a system like that of automobile registration plates
>    should suffice for UAS, others have argued persuasively that each
>    generation of new identifiers should take advantage of advancing
>    technology to protect privacy, to the extent compatible with the
>    transparency needed to protect safety.
> 
> 
> 
> 
> Card, et al.               Expires 3 July 2021                 [Page 17]
> 
> Internet-Draft                  drip-arch                  December 2020
> 
> 
>    A viable architecture for PII protection would be symmetric
>    encryption of the PII using a key known to the UAS and its USS.  An
>    authorized Observer may send the encrypted PII along with the Remote
>    ID (to their UTM Service Provider) to get the plaintext.
>    Alternatively, the authorized Observer may receive the key to
>    directly decrypt all future PII content from the UA.
> <mglt>
> I do have serious doubts this is viable, but
> maybe I am missing the way it works.
> Currently, it seems to me that an Observer
> will get the key(s) used for the encryption
> the communication between the UAS and its
> USS, so it can decrypt the communication. If
> my understanding is correct, I am wondering
> how one can prevent the observer to inject
> traffic to the USS on the behalf of the UA.  
> 
> </mglt>
> 
>  
>  
>  
> On Wed, Dec 30, 2020 at 9:02 PM shuai zhao <[e-mail] <mailto:[e-mail]>> wrote:
>> Dear DRIP,
>>  
>> We have just uploaded a new revision for DRIP architecture, which has a lots of good update:
>> · Added section 3.3 to explain what claims, assertion, attestations, and certification means in DRIP
>> · New section 4.1, which is old section 6, for a clean text organization
>> · Move crowd-sourced concept to a separated sec 6
>> · Lots of other details update across the draft. 
>>  
>> For those of you who know the recent FAA final rules about RID, we will be addressing the necessary changes in the next revision. 
>>  
>> Wish you all have a happy new year! See you in 2021...
>>  
>> -BR,
>> Shuai
>>  
>>> On Dec 30, 2020, at 17:51, [e-mail] <mailto:[e-mail]> wrote:
>>>  
>>> 
>>> A new version of I-D, draft-ietf-drip-arch-07.txt
>>> has been successfully submitted by Shuai Zhao and posted to the
>>> IETF repository.
>>> 
>>> Name: draft-ietf-drip-arch
>>> Revision: 07
>>> Title: Drone Remote Identification Protocol (DRIP) Architecture
>>> Document date: 2020-12-30
>>> Group: drip
>>> Pages: 24
>>> URL:            https://www.ietf.org/archive/id/draft-ietf-drip-arch-07.txt <https://www.ietf.org/archive/id/draft-ietf-drip-arch-07.txt>
>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-drip-arch/ <https://datatracker.ietf.org/doc/draft-ietf-drip-arch/>
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch <https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch>
>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-drip-arch-07 <https://tools.ietf.org/html/draft-ietf-drip-arch-07>
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-07>
>>> 
>>> Abstract:
>>>   This document defines an architecture for protocols and services to
>>>   support Unmanned Aircraft System Remote Identification and tracking
>>>   (UAS RID), plus RID-related communications, including required
>>>   architectural building blocks and their interfaces.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>> 
>>  
>> -- 
>> Tm-rid mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tm-rid <https://www.ietf.org/mailman/listinfo/tm-rid>
> 
>  
> -- 
> Daniel Migault
> Ericsson