Subject: [Drip] Fw: New Version Notification for draft-ietf-drip-auth-04.txt

From: Adam Wiethuechter <[email-masked]>
Date: Mon, 20 Dec 2021 19:29:02 +0000

This version addresses several the items from IETF112:

  *   Appendix A is now filled in and needs review
  *   FEC has also been filled in for Multiple Page and needs review
  *   Examples were updated with hex strings of the pages
  *   Link Type was removed
  *   Frame Type was rearranged in the format - still need some pointers on best way to fill in IANA section for it

Med,

I have an action item for a flow graph that you suggest I should include. Is this for the different Authentication Messages or something else?

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, December 20, 2021 2:24 PM
To: Adam Wiethuechter <[email-masked]>; Robert Moskowitz <[email-masked]>; Stuart Card <[email-masked]>
Subject: New Version Notification for draft-ietf-drip-auth-04.txt

A new version of I-D, draft-ietf-drip-auth-04.txt
has been successfully submitted by Adam Wiethuechter and posted to the
IETF repository.

Name:           draft-ietf-drip-auth
Revision:       04
Title:          DRIP Authentication Formats & Protocols for Broadcast Remote ID
Document date:  2021-12-20
Group:          drip
Pages:          47
URL:            https://www.ietf.org/archive/id/draft-ietf-drip-auth-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-drip-auth/
Html:           https://www.ietf.org/archive/id/draft-ietf-drip-auth-04.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-drip-auth
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-auth-04

Abstract:
   This document describes how to include trust into the ASTM Remote ID
   specification defined in ASTM F3411 under Broadcast Remote ID (RID).
   It defines a few message schemes (sent within the Authentication
   Message) that can be used to authenticate past messages sent by a
   unmanned aircraft (UA) and provide proof of UA trustworthiness even
   in the absence of Internet connectivity at the receiving node.

The IETF Secretariat

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 21 Dec 2021 13:49:33 -0500

My bad.

earlier on, I had Adam remove the signing timestamp for the 
Attestations.  The receiver did not need this, and at the time we were 
really pressed for space.

But Stu kept questioning me on this.  So I went back to the X.509 model 
and looked at what are the use cases for Validity Not Before timestamp.  
I finally came up with one for here, and thus we are adding Validity Not 
Before in and renaming the expiry timestamp to Validity Not After.

The use case goes as follows:

The registration process for DETs will be 'real time'.  You ask, you get 
unless the DET is already registered with your HDA of choice. However, 
it could take some period of time until the DET DNS RRs are available in 
a DNSSEC signed zone.  It could be a day or more!  Thus the HDA's 
attestation of the DET's registration MUST have a Validity Not Before 
timestamp.  The UA MUST not use the DET until a receiver can validate 
the AUTH messages against DNS RR.

Adam is working text for this (the format changes we made in -03 
provided the space relief) into the next ver of drip-auth and this will 
also be in drip-registries.

At least I spent the time, working this out and getting it now, rather 
than later.  It was working on registries and moving the DNS section 
from drip-rid to -registries that cleared up my thinking.

Bob

On 12/20/21 14:29, Adam Wiethuechter wrote:
>   * Frame Type was rearranged in the format - still need some pointers
>     on best way to fill in IANA section for it
>
> Med,
>
> I have an action item for a flow graph that you suggest I should 
> include. Is this for the different Authentication Messages or 
> something else?
>
> --------
> 73,
> Adam T. Wiethuechter
> ------------------------------------------------------------------------
> *From:* [email-masked] <[email-masked]>
> *Sent:* Monday, December 20, 2021 2:24 PM
> *To:* Adam Wiethuechter <[email-masked]>; Robert 
> Moskowitz <[email-masked]>; Stuart Card 
> <[email-masked]>
> *Subject:* New Version Notification for draft-ietf-drip-auth-04.txt
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 21 Dec 2021 16:39:53 -0500

On other point, that I should capture in the docs:

In 'offline' mode, the Validity Not Before timestamp does not matter.  
That is, so what if the DNS has not been updated yet, the receiver only 
is working from a cache of HDA signing keys.

Consider that a rescue team just registered their UAS and now go to the 
emergency area.  But the DNS will not be updated for 24 hours per their 
HDA policy, so what?  Any local receiver would probably be working from 
a cache to validate the registration assertion.  Thus the MUST I have 
below should be a SHOULD.

On 12/21/21 13:49, Robert Moskowitz wrote:
> But Stu kept questioning me on this.  So I went back to the X.509 
> model and looked at what are the use cases for Validity Not Before 
> timestamp.  I finally came up with one for here, and thus we are 
> adding Validity Not Before in and renaming the expiry timestamp to 
> Validity Not After.
>
> The registration process for DETs will be 'real time'.  You ask, you 
> get unless the DET is already registered with your HDA of choice.  
> However, it could take some period of time until the DET DNS RRs are 
> available in a DNSSEC signed zone.  It could be a day or more!  Thus 
> the HDA's attestation of the DET's registration MUST have a Validity 
> Not Before timestamp.  The UA MUST not use the DET until a receiver 
> can validate the AUTH messages against DNS RR.
>
> provided the space relief) into the next ver of drip-auth and this 
> will also be in drip-registries.
>
>>   * Frame Type was rearranged in the format - still need some
>>     pointers on best way to fill in IANA section for it
>>
>> Med,
>>

---

From: "Card, Stu" <[email-masked]>
Date: Tue, 21 Dec 2021 18:41:00 -0500

I am not clear on why an Observer's receiver needs to use DNS to validate
anything received from the UA?

The UA should periodically broadcast all the attestation links from IANA or
at least ICAO down through RAA & HDA to UA. The closer to the root of the
tree, the less frequent the broadcast.

The Observer's cache should have them all anyway, unless some new HDA has
very recently been stood up or the Observer has traveled w/o prior cache
preloading.

DNS is used in DRIP for other purposes:
- preloading the caches;
- checking for key revocations;
- looking up IP addresses of registries holding private information;
- supporting applications beyond RID, starting from IDs received via RID.

I also don't see many UAS operators adopting DRIP if they cannot create &
register an ID, then immediately fly.

What am I missing?

On Tue, Dec 21, 2021, 16:40 Robert Moskowitz <[email-masked]>
wrote:

> That is, so what if the DNS has not been updated yet, the receiver only is
> working from a cache of HDA signing keys.
>
> emergency area.  But the DNS will not be updated for 24 hours per their HDA
> policy, so what?  Any local receiver would probably be working from a cache
> to validate the registration assertion.  Thus the MUST I have below should
> be a SHOULD.
>
> earlier on, I had Adam remove the signing timestamp for the Attestations.
> The receiver did not need this, and at the time we were really pressed for
> space.
>
> and looked at what are the use cases for Validity Not Before timestamp.  I
> finally came up with one for here, and thus we are adding Validity Not
> unless the DET is already registered with your HDA of choice.  However, it
> could take some period of time until the DET DNS RRs are available in a
> DNSSEC signed zone.  It could be a day or more!  Thus the HDA's attestation
> of the DET's registration MUST have a Validity Not Before timestamp.  The
> UA MUST not use the DET until a receiver can validate the AUTH messages
> against DNS RR.
>
> Adam is working text for this (the format changes we made in -03 provided
> the space relief) into the next ver of drip-auth and this will also be in
> drip-registries.
>
> than later.  It was working on registries and moving the DNS section from
> drip-rid to -registries that cleared up my thinking.
>
> Bob
>
>    - Appendix A is now filled in and needs review
>    - FEC has also been filled in for Multiple Page and needs review
>    - Examples were updated with hex strings of the pages
>    - Link Type was removed
>    - Frame Type was rearranged in the format - still need some pointers
> I have an action item for a flow graph that you suggest I should include.
> Is this for the different Authentication Messages or something else?
>
> --------
> 73,
> Adam T. Wiethuechter
> ------------------------------
> <[email-masked]>
> *To:* Adam Wiethuechter <[email-masked]>
> <[email-masked]>; Robert Moskowitz
> <[email-masked]> <[email-masked]>; Stuart Card
> <[email-masked]> <[email-masked]>
> URL:
> https://www.ietf.org/archive/id/draft-ietf-drip-auth-04.txt
> Html:
> https://www.ietf.org/archive/id/draft-ietf-drip-auth-04.html
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>