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

[Robert Moskowitz <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>     >
>
>     -- 
>     Tm-rid mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tm-rid
>
>

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

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