Re: [Drip] Paul Wouters' No Objection on draft-ietf-drip-rid-32: (with COMMENT)

[Robert Moskowitz <[e-mail]>]

Paul,

Thank you for closing out your DISCUSS.  I will address your comments below.

On 8/18/22 21:21, Paul Wouters via Datatracker wrote:
> Paul Wouters has entered the following ballot position for
> draft-ietf-drip-rid-32: No Objection
>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> OLD DISCUSSES:
>
> #1
>
>     Note that if the zone hhit.arpa is ultimately used, some registrar
>     will need to manage this for all HHIT applications.
>
> Regardless of what zone is used, someone needs to keep it operational.
> It might be an attractive target to attack, eg to try and avoid drones
> being shut down. I would feel much better if this zone was optional,
> not mandatory. (but if optional, one could also argue maybe not have it
> at all?)

Sticky item.  But we are in discussions with ICAO as the 'natural' owner 
of this zone.  Well for starters as the only occupant at this time is 
aviation, and it may well be manned aviation sooner than later.  But it 
is also of interest to others, like deep space usage.

So ICAO is best to start with and work out the funding for the basic 
hhit.arpa. management.  And the registration of RAAs (most of which, 
initially will be ICAO Treaty signers).

>     If the HHITs cannot be
>     looked up with services provided by the registrar identified via the
>     embedded hierarchical information or its registration validated by
>     registration attestations messages [drip-authentication], then the
>     HHIT is either fraudulent or revoked/expired.
>
> That's quite catastrophic if there is a Registrar/Registry outage. Would
> all the drones get shot down or would they all be ignored (so they can
> fly to their terrorism target)

Drip-auth goes at lengths through the offline authentication process.  
What a UA MUST send to prove its registration.  Now this DOES require 
the Observer to have some embedded trust root, but then they had to get 
the Observer app that recognizes DETs over other RIDs, so that would 
install at least the root.  So such action is 'unlikely'.  BTW, in USA 
airspace, only DHS can currently take decisive action.  The expectation 
is that once UTM is working, local enforcement will have the information 
to be able to take defensive actions.  But this means either Network RID 
or something like my crowd-sourced-rid.

There is a LOT of discussion about actionable information in other areas 
and here, we are way ahead of the curve.

> #2
>
> As DISCUSS'ED by others,
> https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi-algorithm
> does not seem to have a third field for "status" to denotate RECOMMENDED,
> REQUIRED, etc, even though RFC 7401 creates the registry, uses the terms too
> but doesn't populate a status field. Perhaps this or another short RFC could do
> so.
>
> Also, 3.4.1 calls this "Algorithm profiles" and "Values" but the IANA registry
> calls it "Algorithm Profile" (singular) and "Value" (singular)

This was fixed at least by -31.  I did not go back further to determine 
where I finally got this right.

> #3
>
> Section 3.4.1.1. has a NULL field of variable length ? Or perhaps the
> slash and pipe symbols on those first and second lines got swapped by
> accident?

It is now a pipe and the intent is 2 bytes to word-align the public key 
as in 7401.  At least you caught this as 7401 has the / and I had just 
copied/pasted that here.

>
> #4
>
>     The new EdDSA HI uses [RFC8080] for the IPSECKEY RR encoding:
>
>        Value  Description
>
>        TBD2 (suggested value 4)
>               An EdDSA key is present, in the format defined in [RFC8080]
>
> I have asked the Expert of this Registry whether they are okay with this
> entry to the ipseckey-rr-parameters registry. It might be confusing for IKE.

Draft waiting for IPsecme to adopt as wg item and progress through 
publishing.

> COMMENTS:
>
> #1
>
>     100.hhit.arpa   IN PTR      raa.example.com.
>
> Please add a trailing dot, eg "100.hhit.arpa."
>
> Similarly for:
>
>      100.50.det.uas.icao.int   IN PTR      foo.uss.icao.int.

Done.


> #2
>
>        HIP DNS RR (Resource Record)
>
> Add reference to RFC5205 on its first mention.

Now references 8005.

> #3
>
>      However, this document does not intend to provide a recommendation.
>
> weasel wording. It should probaby just state "this document does not provide
> a recommendation."

fixed in at least -31.

>
> #4
>
>     The individual DETs may be potentially too numerous (e.g., 60 - 600M)
>     and dynamic (e.g., new DETs every minute for some HDAs) to store in a
>     signed, DNS zone.
>
> This can be achieved with online signing. I would remove this speculative
> sentence unless it is backed by some real numbers.

Removed in -30.

thank you.

-33 will be published after discussions with Roman.  I have one change 
there to improve the CTA mapping.  This does not directly impact DRIP, 
but could make this approach (used in drip-registries) more attractive 
to manufacturers.

Bob