Subject: [Dance] Structure for coming work

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 15 Nov 2021 16:15:39 +0100

Hi fellow dancers!

After reading through the initial document and working with Ash on the architecture document, I have come to the conclusion that there may be several different documents needed. Some of the text in the initial document would not apply for other usages, like the device ID naming. Maybe I’m structuring too hard, so please stop me if that’s the case.

Brainstorming openly:

- TLS-modifications: One document with the new extension and the usage Victor outlined in the meeting - CA preference for selection of device credentials
- IoT usage: Device ID naming, connections to other solutions like BRSKI, ACME etc
- Dancing rules: How to define a usage - requirements on naming (from a DNS health perspective), privacy recommendations (don’t put email addresses in DNS), revocations (TTL) etc
- XXYYZZ usage: Like “SIP Dancing for fun and profit” - how to apply Dance to the SIP protocol

Regards,
/O

---

From: Ash Wilson <[email-masked]>
Date: Tue, 16 Nov 2021 10:28:41 -0500

Hi Olle,
I agree that having narrowly-focused documents will be beneficial. There is
a portion of the charter, specifically:
---
DANCE will coordinate with the TLS working group to define any TLS protocol
updates required to support client authentication using DANE.
---
which could require multiple documents to address.

Is it too early to bring the TLS WG into the conversation?

On Mon, Nov 15, 2021 at 10:16 AM Olle E. Johansson <[email-masked]> wrote:

> Hi fellow dancers!
>
> After reading through the initial document and working with Ash on the
> architecture document, I have come to the conclusion that there may be
> several different documents needed. Some of the text in the initial
> document would not apply for other usages, like the device ID naming. Maybe
> I’m structuring too hard, so please stop me if that’s the case.
>
> Brainstorming openly:
>
> - TLS-modifications: One document with the new extension and the usage
> Victor outlined in the meeting - CA preference for selection of device
> credentials
> - Dancing rules: How to define a usage - requirements on naming (from a
> DNS health perspective), privacy recommendations (don’t put email addresses
> in DNS), revocations (TTL) etc
> --
> Dance mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dance
>

-- 

*Ash Wilson * | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 16 Nov 2021 16:36:58 +0100

> On 16 Nov 2021, at 16:28, Ash Wilson <[email-masked]> wrote:
> 
> Hi Olle,
> I agree that having narrowly-focused documents will be beneficial. There is a portion of the charter, specifically:
> ---
Ok. Feels like I’m still on the dance floor then :-)

> Is it too early to bring the TLS WG into the conversation?
Yes, we need to document our thoughts, especially the new piece that Victor brought in and solved during the meeting.

I think of it this way, but Victor and everyone else should feel free to correct this:

“A DANCE client may have multiple credentials, with different usage and issued by different CA authorities. In order for the client to be able to select the proper credential for a TLS session, the server will present a list of acceptable CAs for this session using the TLS “certificate_authorities” extension. If the DANCE client doesn’t have a valid TLS client certificate issued by any of these CAs, the connection will be closed. If the DANCE client has a valid TLS client certificate issued by this CA, the certificate will be used for authentication.”

Certificate authorities TLS extension: https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4 <https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4>

Note “different usage” - I think a DANCE client may have certs for document signing as well. May be the same or a separate key pair and cert.

/O

> 
> On Mon, Nov 15, 2021 at 10:16 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> Hi fellow dancers!
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dance <https://www.ietf.org/mailman/listinfo/dance>
> 
> 
> -- 
> Ash Wilson  | Technical Director
> e: [email-masked] <mailto:[email-masked]> 
> 
> This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 18 Nov 2021 09:33:54 -0500

I have been dancing with a number of docs here.

Went back to DANE to wrap my head around it.  I am talking with the DANE 
advocate in IATA (iata.org) about DANE specifically and then on to 
DANCE.  Note that ICAO (icao.int) Has promugated a basically bridge PKI 
(IATF) with their own CP for participating CAs.  At least DANE usage 
needs to live in this enviroment in avaition.  I do believe that back in 
the summer we made adequate changes in the CP to support Federating CAs 
from different support domains.  I particularly wanted to allow for 
DNS/DANE and things like US law enforcement TRUSTMARK CA work (you got 
to let the police into the airports and they will need digital 
interation with airport security using their already assigned certs).

So on to DANCE and my work in DRIP.  Please look at:

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/
and perhaps
https://datatracker.ietf.org/doc/draft-moskowitz-drip-crowd-sourced-rid/

A UAS will tend to have 2 Identities, one for the UA and one for the 
GCS.  UA Identity is already defined within the UAS ecosystem, and 
draft-ietf-drip-rid provides the IETF's work within this Identity. This 
Identity can also be used in the GCS.  So these IoT devices have their 
already existing/proposed Identity name space.

The regulator powers that be (e.g. FAA, EASA) are mandating a 
registration process.  The DRIP registries draft (currently under wg 
adoption call) needs lots of work but part of the registry process 
SHOULD include some strong identifying stuff.

If HIP is used for the UAS/USS communication, we are already providing 
for HIT information in the DNS.  But DTLS is also defined and here DANCE 
is a great fit.  For some UAS (perhaps commerical delivery UA and 
airtaxi) there may be regulatory requirements for full X.509 certs 
within the IATF, but we can still put those in DANCE.  For some UAS 
(personal, small delivery service), raw public keys in DANCE could be 
more than adequate.

So I will be working up a DANE/DANCE use cases for at least UAS/USS and 
hopefully for broader aviation.

Bob

---

From: Ash Wilson <[email-masked]>
Date: Thu, 18 Nov 2021 11:49:40 -0500

Hi Robert,
This is an interesting use case. After skimming the docs, I think I see two
patterns emerging (please correct me if I'm wrong or over-simplifying):
  Object security: B-RID (broadcast telemetry). This could benefit from a
public key, discoverable by name in DNS, to mitigate spoofed beacon
messages. Is there an opportunity to tie this into a protocol like XARF for
abuse reporting?
  Transport security: N-RID for HIPv2 and TLS. There may be challenges in
bootstrapping trust for devices which don't have direct internet access.
Perhaps as long as at least one device participating in the C2C channel has
Internet access, routing services may be provided and DNSSEC validation in
the stub resolver mitigates on-path attacks.

I think that it deserves coverage in the architecture document. LMK when
you have those docs on DANE mapping for your use case and I'll work it into
the architecture doc.

--

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 18 Nov 2021 14:57:40 -0500

On 11/18/21 11:49, Ash Wilson wrote:
> Hi Robert,
> This is an interesting use case. After skimming the docs, I think I 
> see two patterns emerging (please correct me if I'm wrong or 
> over-simplifying):
>   Object security: B-RID (broadcast telemetry). This could benefit 
> from a public key, discoverable by name in DNS, to mitigate spoofed 
> beacon messages. Is there an opportunity to tie this into a protocol 
> like XARF for abuse reporting?

Don't know XARF.  A quick google gogt me: https://abusix.com/xarf/

Most proposals do not provide any mechanism to detect spoofing. Most UAS 
may end up just sending their CTA 2063-A serial number or some UUID and 
call it a day; they delivered all the FAA/EASA asked for.

We are proposing some real trust claims and are working to get industry 
adoption.  The HHIT as Remote ID is used in a DNS lookup to get the 
public key (HI) in a HIP RR.  The use of the Authentication Messages 
(draft-ietf-drip-auth) provides the proof of ownership of the HHIT, 
registration of HHIT with a HDA, and proof of sending Remote ID messages.

The proof or HDA registration actually provides enough information so 
that a smallish cache of HDA HHIT,HI will provide the proof without 
needing Internet Access and DNS lookup (times of no Internet availablity).

In theory, any device lying about its Remote ID is subject to some yet 
to be defined legal action by FAA (in the US from all those FAA 
enforcement agents at every street corner).  In practice, you have maybe 
5s to react before that terrorist UA is hitting you.  So it becomes an 
IFF.  If you trust it, it may not attack you.  If you don't, send in the 
hawks (Schipol airport solution).

Thus we hope that along this process there will be a "raising of the 
bar" to address the risks to life and limp.

Note that even in the US, there is no right to fly ANYTHING even 1" 
above the ground ANYWHERE (even your backyard).  It is in the laws; the 
FAA controls this.  There is some debate if it starts 1" or 1' above 
ground and there is interagency discussions on the top side between FAA, 
USAF, and NASA.  Ground effect is allowed, but your kites, ballons, etc. 
are all FAA regulated.

> Transport security: N-RID for HIPv2 and TLS. There may be challenges 
> in bootstrapping trust for devices which don't have direct internet 
> access. Perhaps as long as at least one device participating in the 
> C2C channel has Internet access, routing services may be provided and 
> DNSSEC validation in the stub resolver mitigates on-path attacks.

N-RID requires the UAS have internet access.  Minimally via the GCS.  In 
RLOS (Radio Line of Sight) operation, the UA via C2 provides the GCS 
with all it needs to perform N-RID.  In BLOS (Beyond Line of Sight) 
operation, the UA will be required by future regulations (being drafted) 
to have data communications to the USS (e.g. Internet or private sat or 
private IEEE 802.16 {I know of two of these already fielded}).  The 
N-RID rules will mandate secure UAS-USS communications without saying 
what tech.

So in any case, the UAS needs to establish for the duration of the 
operation (technical term for flight) a secure link to its Net_SP (which 
may simply be a function of its USS).  So what credentials for this 
link?  HIPv2 uses the HHIT,HI in the HIP RR for the UAS. DTLS could well 
use TLSA RR.  The PK in both RR are identical.  And I suspect in 
practice one can be derived from the other, but only that in the zone is 
signed via DNSSEC, so in practice the USS may just support both RR.

> I think that it deserves coverage in the architecture document. LMK 
> when you have those docs on DANE mapping for your use case and I'll 
> work it into the architecture doc.

Got a few other items I stuck my neck out for last week.  :)

Will work on it as this is important for the dirp-registry drafting.

>
> On Thu, Nov 18, 2021 at 9:34 AM Robert Moskowitz 
> <[email-masked]> wrote:
>
>     advocate in IATA (iata.org <http://iata.org>) about DANE
>     specifically and then on to
>     DANCE.  Note that ICAO (icao.int <http://icao.int>) Has promugated
>     a basically bridge PKI
>     > After reading through the initial document and working with Ash
>     on the architecture document, I have come to the conclusion that
>     there may be several different documents needed. Some of the text
>     in the initial document would not apply for other usages, like the
>     device ID naming. Maybe I’m structuring too hard, so please stop
>     me if that’s the case.
>     >
>     > Brainstorming openly:
>     >
>     > - TLS-modifications: One document with the new extension and the
>     usage Victor outlined in the meeting - CA preference for selection
>     of device credentials
>     > - Dancing rules: How to define a usage - requirements on naming
>     (from a DNS health perspective), privacy recommendations (don’t
>     put email addresses in DNS), revocations (TTL) etc
> *Ash Wilson *| Technical Director
> *e:[email-masked]
>
> This email and all data transmitted with it contains confidential 
> and/or proprietary information intended solely for the use of 
> individual(s) authorized to receive it. If you are not an intended and 
> authorized recipient you are hereby notified of any use, disclosure, 
> copying or distribution of the information included in this 
> transmission is prohibited and may be unlawful. Please immediately 
> notify the sender by replying to this email and then delete it from 
> your system.
>
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Nov 2021 15:21:15 -0800

>From a process point of view (but still IMHO as I'm writing this without
my co-chair reviewing it first) I think there are multiple pieces to
this for consideration:

1. the base architecture document should describe the following:

> - Dancing rules: How to define a usage - requirements on naming (from
> a DNS health perspective), privacy recommendations (don’t put email
> addresses in DNS), revocations (TTL) etc

2. The architecture and potential solutions for making things actually

> Victor outlined in the meeting - CA preference for selection of device

Which the charter says should happen in the TLS working group, though
the documents can start with ideas from here of course.

Then we'll likely also have individual protocol solution documents that
need protocol-specific sub-discussions, we will likely need small, short
documents or integrations with other WG documents as needed for things

> - XXYYZZ usage: Like “SIP Dancing for fun and profit” - how to apply Dance to the SIP protocol

[a mental image of handing dancing shoes to other WGs is coming to mind]

-- 
Wes Hardaker
USC/ISI