Subject: Re: [Tm-rid] 1st steps - time lines and drafts

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Aug 2019 08:38:30 -0400

I have made some headway on planning and drafts.

First I spoke with the AD for this effort: Eric Vyncke.  This work may 
more likely be a rechartering of HIP than an independent effort; no BOF 
in Singapore, just get to work.  Of course that means I have to get in 
gear and get the last 3 docs finish (well only 2 have my name on them)!

This also has bearing on draft naming.  So for now the Hierarchical HIP 
draft will be:

draft-moskowitz-hip-hierarchical-hip.  I hope to have 00 posted the end 
of next week.

Part of timing is I realize that I should calf off the new crypto into 
its own draft.  This will be:

draft-moskowitz-hip-new-crypto or something like that.  It will have:

EDDSA
SHAKE, cSHAKE, and KMAC.  I am looking at cSHAKE that it might be a 
better hash for making the HIT as properly parameters will mean that no 
truncation is needed.  cSHAKE (in my reading) will make a hash of the 
size you want.  More study needed.
KMAC is a replacement for HMAC which is a big change for KEYMAT in HIP.

One of the considerations will be the size of the sponge for the 
underlying Keccak function.  NIST specified a sponge of b=1600, but that 
is for large messages and parallel processing.  In HIP, everything is 
small messages and for this effort constrained systems.  A sponge of 
b=400 yields 128 bit strength and b=800 for 256 bit strength.  I have 
been told that NIST is working on standardizing these smaller sponge 
sizes, so I plan on using them to help move NIST along.

Finally offering Kedje Jr as an alternative to AES use.  Note that this 
is a bit of a placeholder as NIST is working on such a small crypto 
cipher.  Or so I have been assured.

You can see much of this in my draft-moskowitz-small-crypto, so I have 
text to pull into this new draft, I just have to work out the HIP 
parameters.

There is plenty of work here for anyone that wants to lend a hand. Like 
on CBOR Concise Identity as an addendum to RFC 8002.  And is there value 
to use CBOR and CDDL in HIP?

Bob

On 7/25/19 10:29 AM, Robert Moskowitz wrote:
> Greetings!
>
> Thanks to the FAA stating that they plan on the initial rule making on 
> RemoteID for UAS in September, 2019, the initial work on tm-rid is 
> extremely accelerated.  My understanding is if we have initial draft 
> documents we will then have some time for official RFCs.
>
> There will also need to be some level of interaction with ATSM that 
> has been generating RemoteID standards.  See:
>
> https://github.com/opendroneid/specs
>
> The IETF MAY desire to enter into an MOU with ATSM.  ATSM may want it 
> also.  Note that ATSM claims to be the oldest SDO around.
>
> The work (drafts) I see are listed below.  A charter for this effort 
> SHOULD be within the 1st draft listed.  I will be working with Stu and 
> Adam on a charter that we will display somewhere given that we are 
> pre-BOF here.
>
> We are looking for people interested in writing/reviewing.
>
>
> ====================== Initial Drafts ========================
>
> Trustworthy Multipurpose Remote IDs in UAS
>
> draft-tm-rid-uas
>
> Abstract:    This memo defines the use of Host Identity Tags (HIT) 
> from the Host Identity Protocol (HIP) that can provide a 
> self-asserting trustable identity for Unmanned Aircraft Systems 
> (UAS).  The justification for trust in the IDs, generation and 
> registration of HITs, and use of HITs in UAS messages.
>
>
> Trustworthy Multipurpose Remote IDs in Discovery Services
>
> draft-tm-rid-uas-ds
>
> Abstract:    This memo defines HIT based Discovery Services to obtain 
> both static and dynamic information about UASs.  These services will 
> implement access policy rules to limit what different entities can 
> learn and control of the UASs.
>
>
> Hierarchical HITs for HIP
>
> draft-tm-rid-hierarchical-hip
>
> Abstract:    This document describes the structure of hierarchical 
> HITs to facilitate large deployments in mobile networks.
>
>
> Registration Services for Hierarchical HITs
>
> draft-tm-rid-hierarchical-hip-registration
>
> Abstract:    This document describes the registration of hierarchical 
> HITs (HHIT).  It provides for registrar entities and how they can be 
> found.  It does not describe the policies that registrars must meet as 
> HHIT registrars. It may reference RFC7451.
>
>
> New crypto for HIP
>
> draft-moskowitz-hip-crypto-update
>
> Abstract:    This document adds support for new cryptographic 
> algorithms and methods to HIP. e.g. EDDSA, KMAC, cSHAKE, SHA-3, Kedje.
>
> Note that Kedje is a sort of placeholder as NIST is still working on 
> the 'small' cypher that we want for this project.
>
>
> CBOR formats for HIP
>
> draft-tm-rid-hip-cbor
>
> Abstract:    This document replaces the HIP TLV structures with CBOR CTW.
>
>
> HIP as OAUTH method
>
> draft-tm-rid-hip-oauth
>
> Abstract:    This document adds support of HIP as an OAUTH method
>
> ============================================
>
> Thank you
>

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 1 Aug 2019 10:28:12 -0400

I like the generality & extensibility of CBOR, CDDL, COSE, COID, etc., esp.
as an attempt at future-proofing tm-rid.

I wonder, though, whether all their self-describing headers are too much
overhead for the severely constrained Bluetooth frames of ASTM's proposed
Broadcast Remote ID format.

IETF, as latecomers to the aviation community's party, should look closely
at what ASTM, FAA, ICAO, et al have already concluded or proposed, rather
than regard this as an entirely clean slate; although a truly compelling
solution might get them to change some of their thinking, as it has not yet
been issued as a standard or implemented by UAS makers (beyond
experimentally).

On Thu, Aug 1, 2019, 08:38 Robert Moskowitz <[email-masked]>
wrote:

> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Aug 2019 10:53:29 -0400

I agree that although extensiblity is attractive, the payload cost can 
be prohibitive.  The question wrt to HIP TLVs compared to CBOR should be 
one of efficient design.  HIP was done well before CBOR; its grouping of 
parameter is noted as superior to other's catch as can approach.  So 
care will have to be taken.

COID is significantly better than X.509 for constrained environments.  
Not as good as 'raw' structures introduced by HIP and used elsewhere 
since, but if you need the full capability of a digital certificate in a 
'new', constrained, environment, then it demands careful consideration.  
Of course there are no PKI products that support it.  This too is a 
consideration.

Than, perhaps, there is comparing COSE with secure transport.  If there 
is no transport layer (even Internetworking because it is all 
broadcast), then perhaps COSE has added value.  Again expert review is 
needed.

And I hope that those familiar with ASTM, FAA, ICAO, et al work will be 
able to lend a hand in this evaluation.

On 8/1/19 10:28 AM, Card, Stu wrote:
> I like the generality & extensibility of CBOR, CDDL, COSE, COID, etc., 
> esp. as an attempt at future-proofing tm-rid.
>
> I wonder, though, whether all their self-describing headers are too 
> much overhead for the severely constrained Bluetooth frames of ASTM's 
> proposed Broadcast Remote ID format.
>
> IETF, as latecomers to the aviation community's party, should look 
> closely at what ASTM, FAA, ICAO, et al have already concluded or 
> proposed, rather than regard this as an entirely clean slate; although 
> a truly compelling solution might get them to change some of their 
> thinking, as it has not yet been issued as a standard or implemented 
> by UAS makers (beyond experimentally).
>
> On Thu, Aug 1, 2019, 08:38 Robert Moskowitz <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Aug 2019 16:55:57 -0400

> esp.  as an attempt at future-proofing tm-rid.

So, to be clear: CDDL is a documentation tool. It never travels on the wire.
Some people may be able to generate code from CDDL.  Some people have also
considered how to encode CDDL in... CDDL, which is a meta-meta situation, and
double so, not something to worry about.

COSE, COID are implemented on top of CBOR.
IPv4 and IPv6, DHCP, OSPF, Radius, etc... all include variously (and
differently) encoded "extensions" usually in the form of Type-Length-Value
structures.

    > proposed Broadcast Remote ID format.

My experience with CBOR is that unless you want a flat non-extendable
C-struct, and you will ALWAYS need *ALL* of the fields,  odds are that CBOR
is smaller. CBOR probably does better at encoding than many of the TLV
structures mentioned above, but probably the VLSI guys 20 years ago would
have been annoyed with it's non-32-bit alignment.

    > thinking, as it has not yet been issued as a standard or implemented by
    > UAS makers (beyond experimentally).

Sure.  Can you point at the documents?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Aug 2019 16:57:01 -0400

Robert Moskowitz <[email-masked]> wrote:
    > since, but if you need the full capability of a digital certificate in
    > a 'new', constrained, environment, then it demands careful
    > consideration.  Of course there are no PKI products that support it. 
    > This too is a consideration.

So, no installed based to fight with :-)

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Aug 2019 17:01:27 -0400

> Sure.  Can you point at the documents?

Start with:  https://github.com/opendroneid/specs

That directly impacts what we are planning here.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Aug 2019 17:02:51 -0400

> So, no installed based to fight with :-)

One would hope so.  But a pki provider that wanted to spin up something 
for COID would carry some baggage.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Aug 2019 21:21:07 +0200

On Aug 1, 2019, at 22:55, Michael Richardson <[email-masked]> wrote:
> is smaller. 

Carsten’s compactness principle of data encoding: It is *always* possible to invent something bespoke that is somehow more compact than using an existing data serialization scheme.
(Corollary: It is much harder to invent something that is actually better in more than the compactness dimension in the long run.)

So when the OSCORE people needed to shave off a byte or two from their CBOR-based encoding, they went for a top-level bespoke compression of a structure that continues to use the CBOR data model (see Section 6.3 for that): https://tools.ietf.org/html/rfc8613#section-6.1
This escape hatch is always available.

Apart from that, it *is* possible to come up with CBOR structures that are actually wasteful; I hope there are enough people who have already used CBOR here that this outcome can be avoided.

Grüße, Carsten