From nobody Thu Sep 12 09:53:20 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C9C12011F for ; Thu, 12 Sep 2019 09:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l4vy4J83efP for ; Thu, 12 Sep 2019 09:53:13 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCC2120130 for ; Thu, 12 Sep 2019 09:53:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B0A5F6096F for ; Thu, 12 Sep 2019 12:53:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tpCROTyL8NdG for ; Thu, 12 Sep 2019 12:53:02 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 605F760789 for ; Thu, 12 Sep 2019 12:53:00 -0400 (EDT) References: <156830694118.16565.8372564577620839780.idtracker@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <156830694118.16565.8372564577620839780.idtracker@ietfa.amsl.com> Message-ID: <22dea911-bafe-f3ee-db72-590915931326@labs.htt-consult.com> Date: Thu, 12 Sep 2019 12:52:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156830694118.16565.8372564577620839780.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------9B8D6FD01A19264D7CA9EE74" Content-Language: en-US Archived-At: Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 16:53:18 -0000 This is a multi-part message in MIME format. --------------9B8D6FD01A19264D7CA9EE74 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello all. Finally we are now funded to work on this project.  I am very unhappy at what it took to get to this point.   Fortunately, I have been using the time to put together some notes that I am quickly turning into drafts. So work on tm-rid is now open.  Two more drafts will be posted in the next couple days.  I welcome reviews and comments. Also I will be working with the AD for time at IETF106. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt Date: Thu, 12 Sep 2019 09:49:01 -0700 From: internet-drafts@ietf.org To: Stuart Card , Adam Wiethuechter , Robert Moskowitz , Stuart W. Card A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-hierarchical-hit Revision: 00 Title: Hierarchical HITs for HIPv2 Document date: 2019-09-12 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit Abstract: This document describes using a hierarchical HIT to facilitate large deployments of managed devices. Hierarchical HITs differ from HIPv2 flat HITs by only using 64 bits for mapping the Host Identity, freeing 32 bits to bind in a hierarchy of Registering Entities that provide services to the consumers of hierarchical HITs. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------9B8D6FD01A19264D7CA9EE74 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello all.

Finally we are now funded to work on this project.  I am very unhappy at what it took to get to this point.   Fortunately, I have been using the time to put together some notes that I am quickly turning into drafts.

So work on tm-rid is now open.  Two more drafts will be posted in the next couple days.  I welcome reviews and comments.

Also I will be working with the AD for time at IETF106.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt
Date: Thu, 12 Sep 2019 09:49:01 -0700
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hierarchical-hit
Revision: 00
Title: Hierarchical HITs for HIPv2
Document date: 2019-09-12
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit


Abstract:
This document describes using a hierarchical HIT to facilitate large
deployments of managed devices. Hierarchical HITs differ from HIPv2
flat HITs by only using 64 bits for mapping the Host Identity,
freeing 32 bits to bind in a hierarchy of Registering Entities that
provide services to the consumers of hierarchical HITs.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------9B8D6FD01A19264D7CA9EE74-- From nobody Thu Sep 12 11:33:00 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28031120874 for ; Thu, 12 Sep 2019 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C34z7-xqiQzD for ; Thu, 12 Sep 2019 11:32:57 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FD5120220 for ; Thu, 12 Sep 2019 11:32:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B01436096F for ; Thu, 12 Sep 2019 14:32:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bjZ3TFDzxFE6 for ; Thu, 12 Sep 2019 14:32:45 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id AABA960789 for ; Thu, 12 Sep 2019 14:32:45 -0400 (EDT) From: Robert Moskowitz To: "tm-rid@ietf.org" References: <156830694118.16565.8372564577620839780.idtracker@ietfa.amsl.com> <22dea911-bafe-f3ee-db72-590915931326@labs.htt-consult.com> Message-ID: Date: Thu, 12 Sep 2019 14:32:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <22dea911-bafe-f3ee-db72-590915931326@labs.htt-consult.com> Content-Type: multipart/alternative; boundary="------------344D218748A6C78441943189" Content-Language: en-US Archived-At: Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 18:32:59 -0000 This is a multi-part message in MIME format. --------------344D218748A6C78441943189 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Some points about Hierarchical HITs. The idea is not new.  See draft-moskowitz-hip-04 from 7/01.  One bit was used to identity Hierarchical HITs (HHITs) over flat HITs. Since this concept was removed I am now faced with how to tell the difference in the HIT encoding? HHITs use a different ORCHID construction.  Kind of violation the ORCHID rules.  Remains to be seen if it will take a direct addendum to ORCHID for this.  The HID is included with the HI in computing the ORCHID.  I often wondered if the HIT Suite should have been included.  Since it wasn't we do have to be careful in specifying HIT Suites so it is not possible to have identical BIT-level HIs for different HIT Suites.  I am not attempting to change this part; maybe I should. So given a HIT in the wild (I1, or UAS RID broadcast), how do you know if it is a HHIT.  Instead of burning through HIT suites as I first thought in draft-moskowitz-hierarchical-hip, I am specifying a unique HIT prefix for HHITs. If anyone can see any other way, please speak up.  Again, the ORCHID prefix is specified in the ORCHID RFC.  Will we best do an update to ORCHID? Please chime in. Bob On 9/12/19 12:52 PM, Robert Moskowitz wrote: > Hello all. > > Finally we are now funded to work on this project.  I am very unhappy > at what it took to get to this point.   Fortunately, I have been using > the time to put together some notes that I am quickly turning into drafts. > > So work on tm-rid is now open.  Two more drafts will be posted in the > next couple days.  I welcome reviews and comments. > > Also I will be working with the AD for time at IETF106. > > Bob > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-hip-hierarchical-hit-00.txt > Date: Thu, 12 Sep 2019 09:49:01 -0700 > From: internet-drafts@ietf.org > To: Stuart Card , Adam Wiethuechter > , Robert Moskowitz > , Stuart W. Card > > > > > A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-hip-hierarchical-hit > Revision: 00 > Title: Hierarchical HITs for HIPv2 > Document date: 2019-09-12 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt > Status: > https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/ > Htmlized: > https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit > > > Abstract: > This document describes using a hierarchical HIT to facilitate large > deployments of managed devices. Hierarchical HITs differ from HIPv2 > flat HITs by only using 64 bits for mapping the Host Identity, > freeing 32 bits to bind in a hierarchy of Registering Entities that > provide services to the consumers of hierarchical HITs. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------344D218748A6C78441943189 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Some points about Hierarchical HITs.

The idea is not new.  See draft-moskowitz-hip-04 from 7/01.  One bit was used to identity Hierarchical HITs (HHITs) over flat HITs.

Since this concept was removed I am now faced with how to tell the difference in the HIT encoding?

HHITs use a different ORCHID construction.  Kind of violation the ORCHID rules.  Remains to be seen if it will take a direct addendum to ORCHID for this.  The HID is included with the HI in computing the ORCHID.  I often wondered if the HIT Suite should have been included.  Since it wasn't we do have to be careful in specifying HIT Suites so it is not possible to have identical BIT-level HIs for different HIT Suites.  I am not attempting to change this part; maybe I should.

So given a HIT in the wild (I1, or UAS RID broadcast), how do you know if it is a HHIT.  Instead of burning through HIT suites as I first thought in draft-moskowitz-hierarchical-hip, I am specifying a unique HIT prefix for HHITs.

If anyone can see any other way, please speak up.  Again, the ORCHID prefix is specified in the ORCHID RFC.  Will we best do an update to ORCHID?

Please chime in.

Bob

On 9/12/19 12:52 PM, Robert Moskowitz wrote:
Hello all.

Finally we are now funded to work on this project.  I am very unhappy at what it took to get to this point.   Fortunately, I have been using the time to put together some notes that I am quickly turning into drafts.

So work on tm-rid is now open.  Two more drafts will be posted in the next couple days.  I welcome reviews and comments.

Also I will be working with the AD for time at IETF106.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt
Date: Thu, 12 Sep 2019 09:49:01 -0700
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hierarchical-hit
Revision: 00
Title: Hierarchical HITs for HIPv2
Document date: 2019-09-12
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit


Abstract:
This document describes using a hierarchical HIT to facilitate large
deployments of managed devices. Hierarchical HITs differ from HIPv2
flat HITs by only using 64 bits for mapping the Host Identity,
freeing 32 bits to bind in a hierarchy of Registering Entities that
provide services to the consumers of hierarchical HITs.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------344D218748A6C78441943189-- From nobody Fri Sep 13 07:22:04 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7984412080C for ; Fri, 13 Sep 2019 07:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aP5W3yK8j7Nw for ; Fri, 13 Sep 2019 07:21:58 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4BC120804 for ; Fri, 13 Sep 2019 07:21:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BB0FA6096F for ; Fri, 13 Sep 2019 10:21:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2MFRns9VucTY for ; Fri, 13 Sep 2019 10:21:50 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8BC1860945 for ; Fri, 13 Sep 2019 10:21:50 -0400 (EDT) References: <156838399416.31850.11442811528912608197.idtracker@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <156838399416.31850.11442811528912608197.idtracker@ietfa.amsl.com> Message-ID: <3cd996e9-ec06-3020-4340-01ac15f7cb2e@labs.htt-consult.com> Date: Fri, 13 Sep 2019 10:21:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156838399416.31850.11442811528912608197.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------0A5E6AB472CDB00C26C041EE" Content-Language: en-US Archived-At: Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hhit-registries-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 14:22:03 -0000 This is a multi-part message in MIME format. --------------0A5E6AB472CDB00C26C041EE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Greetings! This is the second of the drafts I have been developing.  It provides the basics for the HHIT registrar activities. I welcome all comments. I am now working on the New crypto draft.  It is still drafty as there are a couple areas needing work.  This includes a KMAC approach to KEYMAT, replacing HMAC.  In fact KMAC completely replaces HMAC (much more efficient). And the new cipher choice is Keyak.  For now.  How do we get the ESP transform number assigned?  What docs do we need for that? I hope to have something ready for New crypto before Monday. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hip-hhit-registries-00.txt Date: Fri, 13 Sep 2019 07:13:14 -0700 From: internet-drafts@ietf.org To: Stuart Card , Adam Wiethuechter , Robert Moskowitz , Stuart W. Card A new version of I-D, draft-moskowitz-hip-hhit-registries-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-hhit-registries Revision: 00 Title: Hierarchical HIT Registries Document date: 2019-09-13 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hhit-registries-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hhit-registries-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hhit-registries Abstract: This document describes using the registration protocol and registries to support hierarchical HITs (HHITs). New and existing HIP parameters are used to communicate Registry Policies and data about the HHIT device and the Registries. Further Registries are expected to provide RVS services for registered HHIT devices. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------0A5E6AB472CDB00C26C041EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Greetings!

This is the second of the drafts I have been developing.  It provides the basics for the HHIT registrar activities.

I welcome all comments.

I am now working on the New crypto draft.  It is still drafty as there are a couple areas needing work.  This includes a KMAC approach to KEYMAT, replacing HMAC.  In fact KMAC completely replaces HMAC (much more efficient). 

And the new cipher choice is Keyak.  For now.  How do we get the ESP transform number assigned?  What docs do we need for that?

I hope to have something ready for New crypto before Monday.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-hhit-registries-00.txt
Date: Fri, 13 Sep 2019 07:13:14 -0700
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-hhit-registries-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hhit-registries
Revision: 00
Title: Hierarchical HIT Registries
Document date: 2019-09-13
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hhit-registries-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hhit-registries-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hhit-registries


Abstract:
This document describes using the registration protocol and
registries to support hierarchical HITs (HHITs). New and existing
HIP parameters are used to communicate Registry Policies and data
about the HHIT device and the Registries. Further Registries are
expected to provide RVS services for registered HHIT devices.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------0A5E6AB472CDB00C26C041EE-- From nobody Fri Sep 13 09:35:27 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DF2120848 for ; Fri, 13 Sep 2019 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLOklWHlTzqL for ; Fri, 13 Sep 2019 09:35:19 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5311912084F for ; Fri, 13 Sep 2019 09:35:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5038D60D1B for ; Fri, 13 Sep 2019 12:35:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Id4irlVQq33E for ; Fri, 13 Sep 2019 12:35:14 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3B4D26096F for ; Fri, 13 Sep 2019 12:35:10 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: <886ca9d1-ef9c-b8fa-9b38-a58cfb6d3047@labs.htt-consult.com> Date: Fri, 13 Sep 2019 12:35:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tm-rid] New drone standard for remote ID submitted for approval X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 16:35:26 -0000 https://spectrum.ieee.org/tech-talk/robotics/drones/drone-remoteid This gives some links for what others are doing in this space and some of what we have to fit into. Unfortunately, there were admin steps that just took a long time. Bob From nobody Sun Sep 15 16:20:11 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4758C120801 for ; Sun, 15 Sep 2019 16:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJm1_4rVuueQ for ; Sun, 15 Sep 2019 16:20:07 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D2212006E for ; Sun, 15 Sep 2019 16:20:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 30FC5615F9 for ; Sun, 15 Sep 2019 19:20:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id luURveaZjINm for ; Sun, 15 Sep 2019 19:19:58 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2755060945 for ; Sun, 15 Sep 2019 19:19:56 -0400 (EDT) References: <156858914178.20795.11859831695115173748.idtracker@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <156858914178.20795.11859831695115173748.idtracker@ietfa.amsl.com> Message-ID: Date: Sun, 15 Sep 2019 19:19:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156858914178.20795.11859831695115173748.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------1546B3F67EDD67F6771AF9F5" Content-Language: en-US Archived-At: Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2019 23:20:10 -0000 This is a multi-part message in MIME format. --------------1546B3F67EDD67F6771AF9F5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This completes the first set of drafts for tm-rid. This draft has a couple drafty areas.  Particularly in the cipher, I need to study Keyak more, but this is what I was advised to use. The Keymat is really a new approach, but pulled directly from NIST sp800-56Cr1. There are a number of other new ways of doing things, leveraging Keccak. So take a read.  I am attending the UAS symposium: https://nuair.org/symposium/ the next couple days along with Stu and Adam.  I expect to have additional information from this gathering. I will be working on the DNS storage of HHITs for updates, plus other items. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hip-new-crypto-00.txt Date: Sun, 15 Sep 2019 16:12:21 -0700 From: internet-drafts@ietf.org To: Stuart Card , Adam Wiethuechter , Robert Moskowitz , Stuart W. Card A new version of I-D, draft-moskowitz-hip-new-crypto-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-new-crypto Revision: 00 Title: New Cryptographic Algorithms for HIP Document date: 2019-09-15 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto Abstract: This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------1546B3F67EDD67F6771AF9F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This completes the first set of drafts for tm-rid.

This draft has a couple drafty areas.  Particularly in the cipher, I need to study Keyak more, but this is what I was advised to use.

The Keymat is really a new approach, but pulled directly from NIST sp800-56Cr1.

There are a number of other new ways of doing things, leveraging Keccak.

So take a read.  I am attending the UAS symposium:  https://nuair.org/symposium/

the next couple days along with Stu and Adam.  I expect to have additional information from this gathering.

I will be working on the DNS storage of HHITs for updates, plus other items.




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-new-crypto-00.txt
Date: Sun, 15 Sep 2019 16:12:21 -0700
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-new-crypto-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 00
Title: New Cryptographic Algorithms for HIP
Document date: 2019-09-15
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto


Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------1546B3F67EDD67F6771AF9F5-- From nobody Wed Sep 18 11:13:15 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E524120801 for ; Wed, 18 Sep 2019 11:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7C0nhCxKgzw for ; Wed, 18 Sep 2019 11:13:11 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAC61200E6 for ; Wed, 18 Sep 2019 11:13:10 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id r5so928126qtd.0 for ; Wed, 18 Sep 2019 11:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/2sWWcuStYC+ui+N8GFTE39wtM8xDAa/sUCiyhnNGg=; b=c+gwhnBTMKyiRGbnsbV7l37H76KOsZU/9dMflfhDhBhKpW5HGyNWAKmGBG8ueDpZ+j bvyJeYHOplU4uVDxGOZBkWEH4jNtM4saBFSBz48PFpEtxFhYZuAo3nKrf0q4IfLiSPVU cUbszyrgaeWqhWsw/XwfRZRzIRO2vFD4TlAxc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B/2sWWcuStYC+ui+N8GFTE39wtM8xDAa/sUCiyhnNGg=; b=SeywFgdvPoD24puUO40+ZORRataF3WP+apX8Zga3KkyOlGVULBeLxj+SKEszFct41y 1jNTSWXVlQ/38qEaruKDkLda2T+uwFmPWSb1hEV9QFqg2IWT887iMyV/DQz/bo/TSy// ZAbpWSjzwqx86ucKqW+GWXchpPq2F1jX++0yo8XkRxg7eBxBcB9IqAoN/MJHbRYH0kFv PA1Ou3QdIc3IwFk09U59Wyh+Su4cjc25C/SVlygqF4pNT+EmaiY90RK99A/+O1+kF7iL p/B6AmNbPR7PtJSZ5Y+DN0870PDvANis0ZtiFq/QbCTl0iTxE96XF3/i3uKgsGAtzIiV WkkA== X-Gm-Message-State: APjAAAVz8wQltwx1nLGEqJ81AbTHc48yvbEp0sOWybThjDcyVHpx6+zB MAqcSUGQA3tdxcCplARo6WSJBrd2UPqWFw9Xk63qR7g3TQ== X-Google-Smtp-Source: APXvYqyQ156oxayiuQirK1Qa2fItZ9HSMadjYitgAaVLWcmvXX2Yvtizccf+etoaWxKi5jcPNjL8yvY3ixHolnDp/RQ= X-Received: by 2002:aed:2469:: with SMTP id s38mr5552679qtc.190.1568830389954; Wed, 18 Sep 2019 11:13:09 -0700 (PDT) MIME-Version: 1.0 References: <156858914178.20795.11859831695115173748.idtracker@ietfa.amsl.com> In-Reply-To: From: "Wiethuechter, Adam" Date: Wed, 18 Sep 2019 14:12:59 -0400 Message-ID: To: Robert Moskowitz Cc: "tm-rid@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001b3c010592d7ca3b" Archived-At: Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 18:13:14 -0000 --0000000000001b3c010592d7ca3b Content-Type: text/plain; charset="UTF-8" Bob, I have reviewed this finally. I am not crypto expert so a lot goes over my head and I have to run down rabbit holes to attempt to understand it but I think I have a broad enough picture now. My comments are in rough order here. I like that you call out that this is targeting "constrained devices and communication" in the introduction - good call. HIP probably needs a bit of an update overall in keying/hashing (I know Stu would love to have SECP256K1 as an option at some point) but that is out of scope here in this draft. In Section 2.2 I see that Keccak and KMAC have the same content in parenthesis. Is this intentional? In Section 3 you make the following comment: "The specification of the HIP parameters and their mapping to HIP packets and packet types is flexible to allow HIP extensions to define new parameters and new protocol behavior." I am wondering if a possible goal is to create a sort of "Constrained Environment Extension (CE_EXT)" to HIP that adds other fundamental changes to how HIP behaves (as well as pull in other extension such as the DEX) on top of these crypto changes. Just food for thought. I noticed in Section 3.2.2 that you have given EdDSA/SHAKE128 a index of "5". I reviewed RFC7401 to find that the index goes up to "3". I checked DEX draft and a few others. What is index 4? I am assuming its in another document that is an addendum to 7401 but I can't find it. Just a nitpick as having everything in one place makes life easier for implementations to not miss something. Same thing goes for Section 3.1.1 and 3.4.1. Section 3.2.1: you reference HOST_ID parameter but point to RFC7041 Section 5.2.19 which is Notification? I think you meant RFC7401 Section 5.2.9. Section 3.3.1, I see that in paragraph 3 you break down into bytes for each r-value. Perhaps do something similar to the paragraph before to be consistent and helpful for those dealing with bytes and not have to do a conversion. Section 4: Add the word "to" in the first sentence - it doesn't flow right ("vary slightly TO the ORCHID generation"). And just clarify; the XOF of cSHAKE removes the need for Encode_96 as cSHAKE will produce a 96 bit value? I need to re-read for the EdDSA again, I feel like I am missing something here in my though process of how HIT generation works. Looks good so far to me. I will read up more on cSHAKE and the other crypto things to hopefully give more insightful comments next time. On Sun, Sep 15, 2019 at 7:20 PM Robert Moskowitz wrote: > This completes the first set of drafts for tm-rid. > > This draft has a couple drafty areas. Particularly in the cipher, I need > to study Keyak more, but this is what I was advised to use. > > The Keymat is really a new approach, but pulled directly from NIST > sp800-56Cr1. > > There are a number of other new ways of doing things, leveraging Keccak. > > So take a read. I am attending the UAS symposium: > https://nuair.org/symposium/ > > the next couple days along with Stu and Adam. I expect to have additional > information from this gathering. > > I will be working on the DNS storage of HHITs for updates, plus other > items. > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-hip-new-crypto-00.txt > Date: Sun, 15 Sep 2019 16:12:21 -0700 > From: internet-drafts@ietf.org > To: Stuart Card , > Adam Wiethuechter > , Robert Moskowitz > , Stuart W. Card > > > > A new version of I-D, draft-moskowitz-hip-new-crypto-00.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-hip-new-crypto > Revision: 00 > Title: New Cryptographic Algorithms for HIP > Document date: 2019-09-15 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-00.txt > Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ > Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto > > > Abstract: > This document provides new cryptographic algorithms to be used with > HIP. The Edwards Elliptic Curve and the Keccak sponge functions are > the main focus. The HIP parameters and processing instructions > impacted by these algorithms are defined. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > -- 73's, Adam T. Wiethuechter --0000000000001b3c010592d7ca3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

I have reviewed th= is finally. I=20 am not crypto expert so a lot goes over my head and I have to run down=20 rabbit holes to attempt to understand it but I think I have a broad=20 enough picture now. My comments are in rough order here.

=
I like that you call out that this is targeting "constraine= d devices and communication" in the introduction - good call. HIP prob= ably needs a bit of an update overall in keying/hashing (I know Stu would l= ove to have SECP256K1 as an option at some point) but that is out of scope = here in this draft.

In Section 2.2 I see that = Keccak and KMAC have the same content in parenthesis. Is this intentional?<= /div>

In Section 3 you make the following comment: "= ;The specification of the HIP parameters and their mapping to HIP packets a= nd packet types is flexible to allow HIP extensions to define new parameter= s and new protocol behavior." I am wondering if a possible goal is to = create a sort of "Constrained Environment Extension (CE_EXT)" to = HIP that adds other fundamental changes to how HIP behaves (as well as pull= in other extension such as the DEX) on top of these crypto changes. Just f= ood for thought.

I noticed in Section 3.2.2 that you have given EdDSA/SHAKE128 a index of=20 "5". I reviewed RFC7401 to find that the index goes up to "3= ". I checked DEX draft and a few others. What is index 4? I am assuming its in=20 another document that is an addendum to 7401 but I can't find it. Just = a nitpick as having everything in one place makes life easier for=20 implementations to not miss something. Same thing goes for Section 3.1.1 an= d 3.4.1.

Section 3.2.1: you reference HOST_ID = parameter but point to RFC7041 Section 5.2.19 which is Notification? I thin= k you meant RFC7401 Section 5.2.9.

Section=20 3.3.1, I see that in paragraph 3 you break down into bytes for each=20 r-value. Perhaps do something similar to the paragraph before to be=20 consistent and helpful for those dealing with bytes and not have to do a conversion.

Section 4: Add the word "to"= ; in the first sentence - it doesn't flow right ("vary slightly TO= the ORCHID generation"). And just clarify; the XOF of cSHAKE removes = the need for Encode_96 as cSHAKE will produce a 96 bit value? I need to re-= read for the EdDSA again, I feel like I am missing something here in my tho= ugh process of how HIT generation works.

Looks goo= d so far to me. I will read up more on cSHAKE and the other crypto things t= o hopefully give more insightful comments next time.


On Sun, Sep 15, 2019 at 7:20 PM Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
=20 =20 =20
This completes the first set of drafts for tm-rid.

This draft has a couple drafty areas.=C2=A0 Particularly in the cipher,= I need to study Keyak more, but this is what I was advised to use.

The Keymat is really a new approach, but pulled directly from NIST sp800-56Cr1.

There are a number of other new ways of doing things, leveraging Keccak.

So take a read.=C2=A0 I am attending the UAS symposium:=C2=A0 https://nuair.org/symposium= /

the next couple days along with Stu and Adam.=C2=A0 I expect to have additional information from this gathering.

I will be working on the DNS storage of HHITs for updates, plus other items.




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-new-crypto-00.txt
Date: Sun, 15 Sep 2019 16:12:21 -0700
From: internet-= drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <s= tu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-new-crypto-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 00
Title: New Cryptographic Algorithms for HIP
Document date: 2019-09-15
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new= -crypto-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypt= o/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-= new-crypto


Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid


--
73's,
Adam T= . Wiethuechter
--0000000000001b3c010592d7ca3b-- From nobody Wed Sep 18 11:54:41 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589DD120BB3 for ; Wed, 18 Sep 2019 11:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgZAvOWoCVo8 for ; Wed, 18 Sep 2019 11:54:36 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36AE120988 for ; Wed, 18 Sep 2019 11:54:35 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id m15so1066839qtq.2 for ; Wed, 18 Sep 2019 11:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=92wYQ/kUIUusyraXK1gkAaPqI3o/n5g46g9uzU/8+ns=; b=g5crE2/10kKob9fAez3jGjvchyDf81sJEcX70zXfAvI7i4eerWaDh6H3CGvZC6rFyc UjDQm8MXxU2/Bks5le6x9+3zWasDzc12J4vN2oVgSs53jEqZ2NgNQT7plWC/pshUw4tF KUP8YYa1yz07gK/mY9KEA2QUV1BzPH/eeN8W4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=92wYQ/kUIUusyraXK1gkAaPqI3o/n5g46g9uzU/8+ns=; b=ZDyaiQmXU/WtXB7h2/DHL5r7cCPgw8/Ugx9H6bv5HhbMkOy99dx7thF685FBfL5aPq H86J1QdqUSie0Glc2aF/du5cn0Y3eR64dhV8xTuxp/dajoQHo5MMh34pJN/tXwv8Gtha +698Q9NRCuh2FKMGWKuosCBP7w00ZjcZMAnaDSK3fT5/0Dby08GOwEMHq+PHjrsavbUj XgbuzbXWTaPu2rHPBxZ+VAXWkTPd3Czdh56W3e+ej7WE85vVP1e8MJEUb2nlENGCl1e6 VE7GmZ7yV+f97tdbdw7z0N724eVSuaG6M1Nu95sQcRaepiG33ecAkQ4xtBiBTsEKEx3F DyKg== X-Gm-Message-State: APjAAAVGrNRz8BSM9KX17Iy0AFVi+KaaUJ4ueTFDFT4ck4XbEnAvi8Oy bbfr247Da5fMg3mSHdxSOC+1aTQB3Hg2z3vVXMk4gghbtQ== X-Google-Smtp-Source: APXvYqxSoPb3m8kGK8wbZy5M3/2YaB9nKkEBLB9uH3bRt8tUq6iIdUV8AHvH6TyAy0yN5NU1rqThCoSA/l0tMs+VkCk= X-Received: by 2002:a0c:e0ca:: with SMTP id x10mr4599325qvk.155.1568832874768; Wed, 18 Sep 2019 11:54:34 -0700 (PDT) MIME-Version: 1.0 References: <156830694118.16565.8372564577620839780.idtracker@ietfa.amsl.com> <22dea911-bafe-f3ee-db72-590915931326@labs.htt-consult.com> In-Reply-To: From: "Wiethuechter, Adam" Date: Wed, 18 Sep 2019 14:54:23 -0400 Message-ID: To: Robert Moskowitz Cc: "tm-rid@ietf.org" Content-Type: multipart/alternative; boundary="00000000000036881e0592d85e94" Archived-At: Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 18:54:39 -0000 --00000000000036881e0592d85e94 Content-Type: text/plain; charset="UTF-8" Bob, Some comments from me that could be useful. Section 3.1: "... provide an assertion as to why the claim should be trusted and any additional side information about the device." To me this is a series of secondary look-ups to other sources of information that the party in question trusts to be valid and up to date. It is out of scope in a sense as this can vary from use case to use case. Bringing it up how you did I think is perfect to setup the discussion of why this draft is being made. Seeing as I created the python script to create HHITs nothing is new here for me either - its just formalized more. I have nothing much to add here other than to confront the question you have brought up in your recent email. I vote that we strongly consider (if my idea below does not seem sound) a new prefix for HHITs on an initial reading. Reading 7401 (Section 5.2.10) it is noted that Suite ID is an octet in length with the top 4 bits being the Suite ID and the lower bits set to 0. This was done purposefully to fulfill this quote out out 7401: "This difference is a measure to accommodate larger HIT Suite IDs if the 16 available values prove insufficient. In that case, one of the 16 values, zero, will be used to indicate that four additional bits of the ORCHID will be used to encode the HIT Suite ID. Hence, the current four-bit HIT Suite IDs only use the four higher-order bits in the ID field. Future documents may define the use of the four lower-order bits in the ID field." Perhaps the lower field could denote if we are an HHIT (or something else) and the upper field stays as is as not to exhaust the list? I may need to think of this more, perhaps this was your first idea but rejected it for a reason I don't see yet. From a programming stand point things could get a bit messy if not standardized correctly, I am hesitant because of this. If we need to update ORCHID RFC for a new prefix does it hurt to also fold in the construction changes as well in that update? On Thu, Sep 12, 2019 at 2:33 PM Robert Moskowitz wrote: > Some points about Hierarchical HITs. > > The idea is not new. See draft-moskowitz-hip-04 from 7/01. One bit was > used to identity Hierarchical HITs (HHITs) over flat HITs. > > Since this concept was removed I am now faced with how to tell the > difference in the HIT encoding? > > HHITs use a different ORCHID construction. Kind of violation the ORCHID > rules. Remains to be seen if it will take a direct addendum to ORCHID for > this. The HID is included with the HI in computing the ORCHID. I often > wondered if the HIT Suite should have been included. Since it wasn't we do > have to be careful in specifying HIT Suites so it is not possible to have > identical BIT-level HIs for different HIT Suites. I am not attempting to > change this part; maybe I should. > > So given a HIT in the wild (I1, or UAS RID broadcast), how do you know if > it is a HHIT. Instead of burning through HIT suites as I first thought in > draft-moskowitz-hierarchical-hip, I am specifying a unique HIT prefix for > HHITs. > > If anyone can see any other way, please speak up. Again, the ORCHID > prefix is specified in the ORCHID RFC. Will we best do an update to ORCHID? > > Please chime in. > > Bob > > On 9/12/19 12:52 PM, Robert Moskowitz wrote: > > Hello all. > > Finally we are now funded to work on this project. I am very unhappy at > what it took to get to this point. Fortunately, I have been using the > time to put together some notes that I am quickly turning into drafts. > > So work on tm-rid is now open. Two more drafts will be posted in the next > couple days. I welcome reviews and comments. > > Also I will be working with the AD for time at IETF106. > > Bob > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-hip-hierarchical-hit-00.txt > Date: Thu, 12 Sep 2019 09:49:01 -0700 > From: internet-drafts@ietf.org > To: Stuart Card , > Adam Wiethuechter > , Robert Moskowitz > , Stuart W. Card > > > > A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-hip-hierarchical-hit > Revision: 00 > Title: Hierarchical HITs for HIPv2 > Document date: 2019-09-12 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt > Status: > https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/ > Htmlized: > https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit > > > Abstract: > This document describes using a hierarchical HIT to facilitate large > deployments of managed devices. Hierarchical HITs differ from HIPv2 > flat HITs by only using 64 bits for mapping the Host Identity, > freeing 32 bits to bind in a hierarchy of Registering Entities that > provide services to the consumers of hierarchical HITs. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > -- > Robert Moskowitz > Owner > HTT Consulting > C: 248-219-2059 > F: 248-968-2824 > E: rgm@labs.htt-consult.com > > There's no limit to what can be accomplished if it doesn't matter who gets > the credit > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > -- 73's, Adam T. Wiethuechter --00000000000036881e0592d85e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

Some comments from me t= hat could be useful.

Section 3.1: "... pr= ovide an assertion as to why the claim should be trusted and any additional= side information about the device." To me this is a series of seconda= ry look-ups to other sources of information that the party in question trus= ts to be valid and up to date. It is out of scope in a sense as this can va= ry from use case to use case. Bringing it up how you did I think is perfect= to setup the discussion of why this draft is being made.

Seeing as I created the python script to create HHITs nothing is ne= w here for me either - its just formalized more. I have nothing much to add= here other than to confront the question you have brought up in your recen= t email. I vote that we strongly consider (if my idea below does not seem s= ound) a new prefix for HHITs on an initial reading.

Reading 7401 (Section 5.2.10) it is noted that Suite ID is an octet = in length with the top 4 bits being the Suite ID and the lower bits set to = 0. This was done purposefully to fulfill this quote out out 7401: "Thi= s difference is a measure to accommodate larger HIT Suite IDs if the 16 ava= ilable values prove insufficient.=C2=A0 In that case, one of the 16 values,= zero, will be used to indicate that four additional bits of the ORCHID wil= l be used to encode the HIT Suite ID.=C2=A0 Hence, the current four-bit HIT= Suite IDs only use the four higher-order bits in the ID field.=C2=A0 Futur= e documents may define the use of the four lower-order bits in the ID field= ."

Perhaps the lower field could denote if we= are an HHIT (or something else) and the upper field stays as is as not to = exhaust the list? I may need to think of this more, perhaps this was your f= irst idea but rejected it for a reason I don't see yet. From a programm= ing stand point things could get a bit messy if not standardized correctly,= I am hesitant because of this.

If we need to upda= te ORCHID RFC for a new prefix does it hurt to also fold in the constructio= n changes as well in that update?

On Thu, Sep 12, 2019 at 2:33 PM = Robert Moskowitz <rgm@labs.h= tt-consult.com> wrote:
=20 =20 =20
Some points about Hierarchical HITs.

The idea is not new.=C2=A0 See draft-moskowitz-hip-04 from 7/01.=C2=A0 = One bit was used to identity Hierarchical HITs (HHITs) over flat HITs.

Since this concept was removed I am now faced with how to tell the difference in the HIT encoding?

HHITs use a different ORCHID construction.=C2=A0 Kind of violation the ORCHID rules.=C2=A0 Remains to be seen if it will take a direct addendu= m to ORCHID for this.=C2=A0 The HID is included with the HI in computing the ORCHID.=C2=A0 I often wondered if the HIT Suite should have been included.=C2=A0 Since it wasn't we do have to be careful in specify= ing HIT Suites so it is not possible to have identical BIT-level HIs for different HIT Suites.=C2=A0 I am not attempting to change this part; maybe I should.

So given a HIT in the wild (I1, or UAS RID broadcast), how do you know if it is a HHIT.=C2=A0 Instead of burning through HIT suites as I first thought in draft-moskowitz-hierarchical-hip, I am specifying a unique HIT prefix for HHITs.

If anyone can see any other way, please speak up.=C2=A0 Again, the ORCH= ID prefix is specified in the ORCHID RFC.=C2=A0 Will we best do an update = to ORCHID?

Please chime in.

Bob

On 9/12/19 12= :52 PM, Robert Moskowitz wrote:
=20 Hello all.

Finally we are now funded to work on this project.=C2=A0 I am very unhappy at what it took to get to this point.=C2=A0=C2=A0 Fortunately= , I have been using the time to put together some notes that I am quickly turning into drafts.

So work on tm-rid is now open.=C2=A0 Two more drafts will be posted i= n the next couple days.=C2=A0 I welcome reviews and comments.

Also I will be working with the AD for time at IETF106.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt
Date: Thu, 12 Sep 2019 09:49:01 -0700
From: internet= -drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hierarchical-hit
Revision: 00
Title: Hierarchical HITs for HIPv2
Document date: 2019-09-12
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-mos= kowitz-hip-hierarchical-hit-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-= hip-hierarchical-hit/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hi= erarchical-hit-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowit= z-hip-hierarchical-hit


Abstract:
This document describes using a hierarchical HIT to facilitate large
deployments of managed devices. Hierarchical HITs differ from HIPv2
flat HITs by only using 64 bits for mapping the Host Identity,
freeing 32 bits to bind in a hierarchy of Registering Entities that
provide services to the consumers of hierarchical HITs.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<= /a>.

The IETF Secretariat


<= /fieldset>

--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid


--
73's,
Adam T= . Wiethuechter
--00000000000036881e0592d85e94-- From nobody Wed Sep 18 13:49:59 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC59E120046 for ; Wed, 18 Sep 2019 13:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77R0RByI-Hcy for ; Wed, 18 Sep 2019 13:49:55 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E71120112 for ; Wed, 18 Sep 2019 13:49:55 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id h126so915318qke.10 for ; Wed, 18 Sep 2019 13:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CTzagsquksJTWcOgV6hPsg8PpLexTVr9gTr4PzCShx0=; b=VG0Q8N3DNh+N7fM9HBRJQIZmj9mew04MpKmjvzJuRAFyn+bzolJOZMbNyXpu1si22w qTcKIMsi8txVF58W5PdXP0hYa137+LceQiiE/1VSraskA6eVdOEENBrJ14W4py8yPef+ YWHcnZAaBBNpU2jpZq8fpz3n6ZWNheNzpVqn4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CTzagsquksJTWcOgV6hPsg8PpLexTVr9gTr4PzCShx0=; b=BZOhJD72juJtZMoXm9F1/gckUxklu0yVul2aUvmO9QaWF1VuYg1JAYBqNB7VbO/Sjb +ol3WtmEOOuHStyWv4rWQ0B1wHqjs4d/d7CzeVadPZVM/XC3sVhiGUMoLdzlDBAoNLWc lje1gWX7cHcuoi/AhJ2+AWURfMeSm5qBZYSIrKLpP16B+ZVYOIFtCCxEsv2hvWu7+/7x Ry4tX9JfaiRIuLS++F9sSv2wdOIpf7BYwP26BPGrzLvSBFEkj1SBSBhV7+RMJm4/QhiB YV81rOLH8eJ1wuWuS7C9fPp4efH8P95W70Ub0PhEOUzd1hrMUqnp1TXLIPURGnrrG1fJ 2NkA== X-Gm-Message-State: APjAAAVHi5C17bWPcsZbPFMw9roTSzK4fMeRvNoBiw9/rX9Q/1Lvjuy2 MP4kWnGyS+Qtrh2YKC4zAeIRd7v+qY7/XFktwXSdrR8= X-Google-Smtp-Source: APXvYqxnPCdFdNW2r6y1KTNW9Im0kCQm1Y4/x79JUVOK+9QbTnbAd7aN4lfYzyeZtyQIpZ0MJtWM1KdzdpZiSe6iQWE= X-Received: by 2002:a37:8044:: with SMTP id b65mr6083260qkd.138.1568839794792; Wed, 18 Sep 2019 13:49:54 -0700 (PDT) MIME-Version: 1.0 References: <156838399416.31850.11442811528912608197.idtracker@ietfa.amsl.com> <3cd996e9-ec06-3020-4340-01ac15f7cb2e@labs.htt-consult.com> In-Reply-To: <3cd996e9-ec06-3020-4340-01ac15f7cb2e@labs.htt-consult.com> From: "Wiethuechter, Adam" Date: Wed, 18 Sep 2019 16:49:43 -0400 Message-ID: To: Robert Moskowitz Cc: "tm-rid@ietf.org" Content-Type: multipart/alternative; boundary="000000000000adaed10592d9fa60" Archived-At: Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hhit-registries-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 20:49:58 -0000 --000000000000adaed10592d9fa60 Content-Type: text/plain; charset="UTF-8" Bob, I think of all the drafts I have read today this is the most concise and detailed - I have no comments as I think you covered quite a bit clearly. A lot of this document is pointing out things that need to be dealt with by the HDA (hence being out of scope as its case by case) which is a good choice. Perhaps the next step is to setup some example(s) to work through to get some more detail (and some flow diagrams of traffic between hosts and HDA layouts). Most likely this will result in more detail and specific drafts to a specific use case. For UAS applications the registration will mostly be out of band I think (unless re-registering). So I will try to think how best to apply this and the other drafts in that context and problem space. On Fri, Sep 13, 2019 at 10:22 AM Robert Moskowitz wrote: > Greetings! > > This is the second of the drafts I have been developing. It provides the > basics for the HHIT registrar activities. > > I welcome all comments. > > I am now working on the New crypto draft. It is still drafty as there are > a couple areas needing work. This includes a KMAC approach to KEYMAT, > replacing HMAC. In fact KMAC completely replaces HMAC (much more > efficient). > > And the new cipher choice is Keyak. For now. How do we get the ESP > transform number assigned? What docs do we need for that? > > I hope to have something ready for New crypto before Monday. > > Bob > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-hip-hhit-registries-00.txt > Date: Fri, 13 Sep 2019 07:13:14 -0700 > From: internet-drafts@ietf.org > To: Stuart Card , > Adam Wiethuechter > , Robert Moskowitz > , Stuart W. Card > > > > A new version of I-D, draft-moskowitz-hip-hhit-registries-00.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-hip-hhit-registries > Revision: 00 > Title: Hierarchical HIT Registries > Document date: 2019-09-13 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hhit-registries-00.txt > Status: > https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/ > Htmlized: > https://tools.ietf.org/html/draft-moskowitz-hip-hhit-registries-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hhit-registries > > > Abstract: > This document describes using the registration protocol and > registries to support hierarchical HITs (HHITs). New and existing > HIP parameters are used to communicate Registry Policies and data > about the HHIT device and the Registries. Further Registries are > expected to provide RVS services for registered HHIT devices. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > -- 73's, Adam T. Wiethuechter --000000000000adaed10592d9fa60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

I think of all the draf= ts I have read today this is the most concise and detailed - I have no comm= ents as I think you covered quite a bit clearly. A lot of this document is = pointing out things that need to be dealt with by the HDA (hence being out = of scope as its case by case) which is a good choice. Perhaps the next step= is to setup some example(s) to work through to get some more detail (and s= ome flow diagrams of traffic between hosts and HDA layouts). Most likely th= is will result in more detail and specific drafts to a specific use case.

For UAS applications the registration will most= ly be out of band I think (unless re-registering). So I will try to think h= ow best to apply this and the other drafts in that context and problem spac= e.

On Fri, Sep 13, 2019 at 10:22 AM Robert Moskowitz <rgm@labs.htt-consult.com> wrote= :
=20 =20 =20
Greetings!

This is the second of the drafts I have been developing.=C2=A0 It provides the basics for the HHIT registrar activities.

I welcome all comments.

I am now working on the New crypto draft.=C2=A0 It is still drafty as there are a couple areas needing work.=C2=A0 This includes a KMAC approach to KEYMAT, replacing HMAC.=C2=A0 In fact KMAC completely replaces HMAC (much more efficient).=C2=A0

And the new cipher choice is Keyak.=C2=A0 For now.=C2=A0 How do we get = the ESP transform number assigned?=C2=A0 What docs do we need for that?

I hope to have something ready for New crypto before Monday.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-hhit-registries-00.txt
Date: Fri, 13 Sep 2019 07:13:14 -0700
From: internet-d= rafts@ietf.org
To: Stuart Card = <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <st= u.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-hhit-registries-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hhit-registries
Revision: 00
Title: Hierarchical HIT Registries
Document date: 2019-09-13
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip= -hhit-registries-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-re= gistries/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hhit-registries= -00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hhit= -registries


Abstract:
This document describes using the registration protocol and
registries to support hierarchical HITs (HHITs). New and existing
HIP parameters are used to communicate Registry Policies and data
about the HHIT device and the Registries. Further Registries are
expected to provide RVS services for registered HHIT devices.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid


--
73's,
Adam T= . Wiethuechter
--000000000000adaed10592d9fa60-- From nobody Wed Sep 18 20:11:36 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2E5120119 for ; Wed, 18 Sep 2019 20:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFCjqVxVYkIc for ; Wed, 18 Sep 2019 20:11:31 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CAE1200FE for ; Wed, 18 Sep 2019 20:11:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3DBC662127; Wed, 18 Sep 2019 23:11:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oyuZxWQUdOXD; Wed, 18 Sep 2019 23:11:16 -0400 (EDT) Received: from lx140e.htt-consult.com (rrcs-50-75-106-130.nys.biz.rr.com [50.75.106.130]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CAA0E60029; Wed, 18 Sep 2019 23:11:15 -0400 (EDT) To: "Wiethuechter, Adam" Cc: "tm-rid@ietf.org" References: <156830694118.16565.8372564577620839780.idtracker@ietfa.amsl.com> <22dea911-bafe-f3ee-db72-590915931326@labs.htt-consult.com> From: Robert Moskowitz Message-ID: <6a761520-08aa-be5a-159c-b566382fc0e0@labs.htt-consult.com> Date: Wed, 18 Sep 2019 23:11:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A98AF692359A54CCCD7C3F97" Content-Language: en-US Archived-At: Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 03:11:34 -0000 This is a multi-part message in MIME format. --------------A98AF692359A54CCCD7C3F97 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/18/19 2:54 PM, Wiethuechter, Adam wrote: > Bob, > > Some comments from me that could be useful. > > Section 3.1: "... provide an assertion as to why the claim should be > trusted and any additional side information about the device." To me > this is a series of secondary look-ups to other sources of information > that the party in question trusts to be valid and up to date. It is > out of scope in a sense as this can vary from use case to use case. > Bringing it up how you did I think is perfect to setup the discussion > of why this draft is being made. This is not so uncommon in an Introduction that provides some of the justification for the rest of the document.  It basically states why have a hierarchy in the HITs at all.  I feel we have a better understanding of where HHITs can be used today then we did when I first proposed this back in Dec '99: draft-moskowitz-hip-arch-00 > > Seeing as I created the python script to create HHITs nothing is new > here for me either - its just formalized more. I have nothing much to > add here other than to confront the question you have brought up in > your recent email. I vote that we strongly consider (if my idea below > does not seem sound) a new prefix for HHITs on an initial reading. > > Reading 7401 (Section 5.2.10) it is noted that Suite ID is an octet in > length with the top 4 bits being the Suite ID and the lower bits set > to 0. This was done purposefully to fulfill this quote out out 7401: > "This difference is a measure to accommodate larger HIT Suite IDs if > the 16 available values prove insufficient.  In that case, one of the > 16 values, zero, will be used to indicate that four additional bits of > the ORCHID will be used to encode the HIT Suite ID.  Hence, the > current four-bit HIT Suite IDs only use the four higher-order bits in > the ID field.  Future documents may define the use of the four > lower-order bits in the ID field." > > Perhaps the lower field could denote if we are an HHIT (or something > else) and the upper field stays as is as not to exhaust the list? I > may need to think of this more, perhaps this was your first idea but > rejected it for a reason I don't see yet. From a programming stand > point things could get a bit messy if not standardized correctly, I am > hesitant because of this. I am very hesitant to define HHIT suites by in a sense burning up the whole 9 - 16 space. Plus I would have to take those 4 bits from something.  Either the HID or the hash. HHIT HIT suite ID can be any of the current, plus the new ones I am defining.  Thus, for now, I will stay with a new prefix. > > If we need to update ORCHID RFC for a new prefix does it hurt to also > fold in the construction changes as well in that update? Possibly.  We will have to see what the sense is from the chairs and AD on what documents to update. > > On Thu, Sep 12, 2019 at 2:33 PM Robert Moskowitz > > wrote: > > Some points about Hierarchical HITs. > > The idea is not new.  See draft-moskowitz-hip-04 from 7/01. One > bit was used to identity Hierarchical HITs (HHITs) over flat HITs. > > Since this concept was removed I am now faced with how to tell the > difference in the HIT encoding? > > HHITs use a different ORCHID construction.  Kind of violation the > ORCHID rules.  Remains to be seen if it will take a direct > addendum to ORCHID for this.  The HID is included with the HI in > computing the ORCHID.  I often wondered if the HIT Suite should > have been included.  Since it wasn't we do have to be careful in > specifying HIT Suites so it is not possible to have identical > BIT-level HIs for different HIT Suites.  I am not attempting to > change this part; maybe I should. > > So given a HIT in the wild (I1, or UAS RID broadcast), how do you > know if it is a HHIT.  Instead of burning through HIT suites as I > first thought in draft-moskowitz-hierarchical-hip, I am specifying > a unique HIT prefix for HHITs. > > If anyone can see any other way, please speak up.  Again, the > ORCHID prefix is specified in the ORCHID RFC.  Will we best do an > update to ORCHID? > > Please chime in. > > Bob > > On 9/12/19 12:52 PM, Robert Moskowitz wrote: >> Hello all. >> >> Finally we are now funded to work on this project.  I am very >> unhappy at what it took to get to this point. Fortunately, I have >> been using the time to put together some notes that I am quickly >> turning into drafts. >> >> So work on tm-rid is now open.  Two more drafts will be posted in >> the next couple days.  I welcome reviews and comments. >> >> Also I will be working with the AD for time at IETF106. >> >> Bob >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-moskowitz-hip-hierarchical-hit-00.txt >> Date: Thu, 12 Sep 2019 09:49:01 -0700 >> From: internet-drafts@ietf.org >> To: Stuart Card >> , Adam Wiethuechter >> >> , Robert Moskowitz >> , >> Stuart W. Card >> >> >> >> >> >> A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt >> has been successfully submitted by Robert Moskowitz and posted to the >> IETF repository. >> >> Name: draft-moskowitz-hip-hierarchical-hit >> Revision: 00 >> Title: Hierarchical HITs for HIPv2 >> Document date: 2019-09-12 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/ >> Htmlized: >> https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit >> >> >> Abstract: >> This document describes using a hierarchical HIT to facilitate large >> deployments of managed devices. Hierarchical HITs differ from HIPv2 >> flat HITs by only using 64 bits for mapping the Host Identity, >> freeing 32 bits to bind in a hierarchy of Registering Entities that >> provide services to the consumers of hierarchical HITs. >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at >> tools.ietf.org . >> >> The IETF Secretariat >> >> > > -- > Robert Moskowitz > Owner > HTT Consulting > C: 248-219-2059 > F: 248-968-2824 > E: rgm@labs.htt-consult.com > > There's no limit to what can be accomplished if it doesn't matter > who gets the credit > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > > > > -- > 73's, > Adam T. Wiethuechter -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------A98AF692359A54CCCD7C3F97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 9/18/19 2:54 PM, Wiethuechter, Adam wrote:
Bob,

Some comments from me that could be useful.

Section 3.1: "... provide an assertion as to why the claim should be trusted and any additional side information about the device." To me this is a series of secondary look-ups to other sources of information that the party in question trusts to be valid and up to date. It is out of scope in a sense as this can vary from use case to use case. Bringing it up how you did I think is perfect to setup the discussion of why this draft is being made.

This is not so uncommon in an Introduction that provides some of the justification for the rest of the document.  It basically states why have a hierarchy in the HITs at all.  I feel we have a better understanding of where HHITs can be used today then we did when I first proposed this back in Dec '99:

draft-moskowitz-hip-arch-00




Seeing as I created the python script to create HHITs nothing is new here for me either - its just formalized more. I have nothing much to add here other than to confront the question you have brought up in your recent email. I vote that we strongly consider (if my idea below does not seem sound) a new prefix for HHITs on an initial reading.

Reading 7401 (Section 5.2.10) it is noted that Suite ID is an octet in length with the top 4 bits being the Suite ID and the lower bits set to 0. This was done purposefully to fulfill this quote out out 7401: "This difference is a measure to accommodate larger HIT Suite IDs if the 16 available values prove insufficient.  In that case, one of the 16 values, zero, will be used to indicate that four additional bits of the ORCHID will be used to encode the HIT Suite ID.  Hence, the current four-bit HIT Suite IDs only use the four higher-order bits in the ID field.  Future documents may define the use of the four lower-order bits in the ID field."

Perhaps the lower field could denote if we are an HHIT (or something else) and the upper field stays as is as not to exhaust the list? I may need to think of this more, perhaps this was your first idea but rejected it for a reason I don't see yet. From a programming stand point things could get a bit messy if not standardized correctly, I am hesitant because of this.

I am very hesitant to define HHIT suites by in a sense burning up the whole 9 - 16 space.

Plus I would have to take those 4 bits from something.  Either the HID or the hash.

HHIT HIT suite ID can be any of the current, plus the new ones I am defining.  Thus, for now, I will stay with a new prefix.


If we need to update ORCHID RFC for a new prefix does it hurt to also fold in the construction changes as well in that update?

Possibly.  We will have to see what the sense is from the chairs and AD on what documents to update.


On Thu, Sep 12, 2019 at 2:33 PM Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
Some points about Hierarchical HITs.

The idea is not new.  See draft-moskowitz-hip-04 from 7/01.  One bit was used to identity Hierarchical HITs (HHITs) over flat HITs.

Since this concept was removed I am now faced with how to tell the difference in the HIT encoding?

HHITs use a different ORCHID construction.  Kind of violation the ORCHID rules.  Remains to be seen if it will take a direct addendum to ORCHID for this.  The HID is included with the HI in computing the ORCHID.  I often wondered if the HIT Suite should have been included.  Since it wasn't we do have to be careful in specifying HIT Suites so it is not possible to have identical BIT-level HIs for different HIT Suites.  I am not attempting to change this part; maybe I should.

So given a HIT in the wild (I1, or UAS RID broadcast), how do you know if it is a HHIT.  Instead of burning through HIT suites as I first thought in draft-moskowitz-hierarchical-hip, I am specifying a unique HIT prefix for HHITs.

If anyone can see any other way, please speak up.  Again, the ORCHID prefix is specified in the ORCHID RFC.  Will we best do an update to ORCHID?

Please chime in.

Bob

On 9/12/19 12:52 PM, Robert Moskowitz wrote:
Hello all.

Finally we are now funded to work on this project.  I am very unhappy at what it took to get to this point.   Fortunately, I have been using the time to put together some notes that I am quickly turning into drafts.

So work on tm-rid is now open.  Two more drafts will be posted in the next couple days.  I welcome reviews and comments.

Also I will be working with the AD for time at IETF106.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.txt
Date: Thu, 12 Sep 2019 09:49:01 -0700
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hierarchical-hit
Revision: 00
Title: Hierarchical HITs for HIPv2
Document date: 2019-09-12
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit


Abstract:
This document describes using a hierarchical HIT to facilitate large
deployments of managed devices. Hierarchical HITs differ from HIPv2
flat HITs by only using 64 bits for mapping the Host Identity,
freeing 32 bits to bind in a hierarchy of Registering Entities that
provide services to the consumers of hierarchical HITs.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--
Tm-rid mailing list
Tm-rid@ietf.org
https://www.ietf.org/mailman/listinfo/tm-rid


--
73's,
Adam T. Wiethuechter

--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------A98AF692359A54CCCD7C3F97-- From nobody Fri Sep 20 13:49:18 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77804120114 for ; Fri, 20 Sep 2019 13:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwJzFgT_Fqht for ; Fri, 20 Sep 2019 13:49:14 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761CE120121 for ; Fri, 20 Sep 2019 13:49:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C300A62129 for ; Fri, 20 Sep 2019 16:49:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RsaarSizva4A for ; Fri, 20 Sep 2019 16:49:09 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 547AB60029 for ; Fri, 20 Sep 2019 16:49:09 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: <4f426c49-4743-2c40-942f-d562a39170ec@labs.htt-consult.com> Date: Fri, 20 Sep 2019 16:48:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Tm-rid] HIP - TM-RID meeting in Singapore X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 20:49:16 -0000 This is a duplicate of my post to the HIPSEC list, for those not on the HIPSEC list.... I am in discussion with Ganzalo and Eric about a HIP session in Singapore. The focus is the new work to support "Trustworthy Multipurpose RemoteID" with the target user of UAS. This week I attended the nuair.org UAS Symposium outside of Syracuse NY and received considerable support for HITs as RemoteIDs (along with the other expected formats).  This effort has funding from CLUE (I was told what that means and what piece of legislation set it up, but...). I have the 1st versions of the 1st 3 drafts.  More to follow. I would like to see hackathon efforts at Singapore (unfortunately we cannot fly drones in the hackathon room, perhaps we can get them suspended from the ceiling).  Also including HIPv2 software interop testing. It is early to actually have an agenda, but the question is: When during the week. How long a session. Eric was thinking a short session on Friday. I will be there for the whole week, so Friday morning works for me. Who would also be there.  Who could not. A short session at the end of the week SHOULD be ok. What about earlier in the week?  Who would attend?  What are conflicts (SAAG, CFRG)? Eric needs to move forward on scheduling deadlines are coming up. Please chime in. Bob From nobody Mon Sep 23 09:05:55 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9D120137 for ; Mon, 23 Sep 2019 09:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdqEEFNv5DeT for ; Mon, 23 Sep 2019 09:05:45 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7682F120152 for ; Mon, 23 Sep 2019 09:05:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D26536210D for ; Mon, 23 Sep 2019 12:05:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wrFxLFr99HMc for ; Mon, 23 Sep 2019 12:05:39 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8FCFB607A5 for ; Mon, 23 Sep 2019 12:05:37 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: Date: Mon, 23 Sep 2019 12:05:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Tm-rid] OpenDrone ID spec X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 16:05:49 -0000 tm-rid members: I will start this with a pointer to the current OpenDroneID spec (0.64.3): https://www.opendroneid.org/ Code and other items are available at: https://github.com/opendroneid At the Symposium last week, a comment was made that this version is out to ballot to the ASTM members.  We have identified a few areas of concern on this version.  More on that later. First, this messaging standard was developed to fit within the BT 4 “Beacon Advertisements” which effectively limits the messages to 25 bytes.  24 bytes are available to each OpenDroneID message. Note that the BT 4 Beacon Advertisements include a 1 byte counter managed by the application (it seems). Beacon Advertisements were chosen as these (it is claimed) are the only BT messages available to an application to send and receive that do not require pairing.  BT does not have an equivalent to IEEE 802.11OCB (at least for BT4).  BT4 itself was selected as the base transport to include the largest number of UAVs on the market. Development platforms include:  UAVs, smartphones, tablets. Further claimed that UAVs are in listen mode only.  These messages cannot be used by the ground to get specific information from the UAV.  I have problems believing this, but will use this limit for now. Note that BT4 has a claimed range of 300M.  At 60MPH (~90KPM), the UAV will cover that range in ~11sec.  Beacon range MAY be longer due to their short size, much like 802.11 Beacons. Further BT5 supports 255 bytes for Beacons.  This is important to know when you look at the Auth message size limit. There are 5 messages defined in this draft.  I will discuss each. Basic ID Message We are going to work toward adding HIT as a standard ID type, per RFC 7401.  HHITs per draft-moskowitz-hip-hierarchical-hit will be an update to 7401, so I do not feel that OpenDrone spec needs to allocate a type for HHIT. This message allows for 20 bytes for ID and has 3 bytes reserved.  I do not know anyway to authenticate this message within this limitation.  Give me 255 bytes and much can be done!  That may be in ver 2.0.  More on this later. Location/Vector Message Stuffed into the 24 byte limit.  Nothing can be added to this message.  The BAD thing about this message is what UAV is it from? You have a cluster of UAVs all sending these messages, they are close to useless.  If any message in this spec needs lengthening, this is it.  BT does have a 6 byte device? address.  Perhaps they are expecting this to be used, but it is not called out in the spec. Authentication Message This is defined as a static message.  That is it never changes for a flight.  We are calling for it to be dynamic, and Adam has a proposal to use this to authenticate a group of prior messages.  The HI private key will be used as the sig for our Extended Auth messages.  This will be discussed in a separate message and one of the important outputs of this effort. Self ID Message This is text about the UAV/mission.  23 bytes is not enough for many uses.  We are going to recommend this (like Auth), allow for extending to a max of 255 bytes.  At this point we are not thinking of adding signing to it, rather the Extended Auth message will cover it. System Message Similar issues as with Location/Vector.  Plus the UPS application has the GCS (the UPS truck!) moving rather rapidly so no slow updates to content for them. This is a quick presentation of the OpenDroneID messages.  Our initial focus will be to place HITs in the Basic Message, and to define an Extended Authentication Message that will strongly bind the HIT to a group of messages by using the HI private key in a signature operation. More to follow. Bob From nobody Mon Sep 23 09:53:39 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193361201C6 for ; Mon, 23 Sep 2019 09:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxDuZ-nMApaQ for ; Mon, 23 Sep 2019 09:53:27 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF44120909 for ; Mon, 23 Sep 2019 09:53:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CDE826210D for ; Mon, 23 Sep 2019 12:53:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gDcGOue3GcjT for ; Mon, 23 Sep 2019 12:53:17 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 09912607A5 for ; Mon, 23 Sep 2019 12:53:13 -0400 (EDT) From: Robert Moskowitz To: "tm-rid@ietf.org" References: Message-ID: <13fd3f0c-a1b5-4746-38ea-0e6e076ad132@labs.htt-consult.com> Date: Mon, 23 Sep 2019 12:53:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------17D2F6BDE72AB906DB98831C" Content-Language: en-US Archived-At: Subject: Re: [Tm-rid] OpenDrone ID spec X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 16:53:38 -0000 This is a multi-part message in MIME format. --------------17D2F6BDE72AB906DB98831C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Oh, I left as one of this group's activities is using HIP for HIT registry with UAV management systems (e.g. UTMs). Bob On 9/23/19 12:05 PM, Robert Moskowitz wrote: > tm-rid members: > > I will start this with a pointer to the current OpenDroneID spec > (0.64.3): > > https://www.opendroneid.org/ > > Code and other items are available at: > > https://github.com/opendroneid > > At the Symposium last week, a comment was made that this version is > out to ballot to the ASTM members.  We have identified a few areas of > concern on this version.  More on that later. > > First, this messaging standard was developed to fit within the BT 4 > “Beacon Advertisements” which effectively limits the messages to 25 > bytes.  24 bytes are available to each OpenDroneID message. > > Note that the BT 4 Beacon Advertisements include a 1 byte counter > managed by the application (it seems). > > Beacon Advertisements were chosen as these (it is claimed) are the > only BT messages available to an application to send and receive that > do not require pairing.  BT does not have an equivalent to IEEE > 802.11OCB (at least for BT4).  BT4 itself was selected as the base > transport to include the largest number of UAVs on the market. > > Development platforms include:  UAVs, smartphones, tablets. > > Further claimed that UAVs are in listen mode only.  These messages > cannot be used by the ground to get specific information from the > UAV.  I have problems believing this, but will use this limit for now. > > Note that BT4 has a claimed range of 300M.  At 60MPH (~90KPM), the UAV > will cover that range in ~11sec.  Beacon range MAY be longer due to > their short size, much like 802.11 Beacons. > > Further BT5 supports 255 bytes for Beacons.  This is important to know > when you look at the Auth message size limit. > > There are 5 messages defined in this draft.  I will discuss each. > > > Basic ID Message > > We are going to work toward adding HIT as a standard ID type, per RFC > 7401.  HHITs per draft-moskowitz-hip-hierarchical-hit will be an > update to 7401, so I do not feel that OpenDrone spec needs to allocate > a type for HHIT. > > This message allows for 20 bytes for ID and has 3 bytes reserved. I do > not know anyway to authenticate this message within this limitation.  > Give me 255 bytes and much can be done!  That may be in ver 2.0.  More > on this later. > > > Location/Vector Message > > Stuffed into the 24 byte limit.  Nothing can be added to this > message.  The BAD thing about this message is what UAV is it from? You > have a cluster of UAVs all sending these messages, they are close to > useless.  If any message in this spec needs lengthening, this is it.  > BT does have a 6 byte device? address.  Perhaps they are expecting > this to be used, but it is not called out in the spec. > > > Authentication Message > > This is defined as a static message.  That is it never changes for a > flight.  We are calling for it to be dynamic, and Adam has a proposal > to use this to authenticate a group of prior messages. The HI private > key will be used as the sig for our Extended Auth messages.  This will > be discussed in a separate message and one of the important outputs of > this effort. > > > Self ID Message > > This is text about the UAV/mission.  23 bytes is not enough for many > uses.  We are going to recommend this (like Auth), allow for extending > to a max of 255 bytes.  At this point we are not thinking of adding > signing to it, rather the Extended Auth message will cover it. > > > System Message > > Similar issues as with Location/Vector.  Plus the UPS application has > the GCS (the UPS truck!) moving rather rapidly so no slow updates to > content for them. > > > > This is a quick presentation of the OpenDroneID messages.  Our initial > focus will be to place HITs in the Basic Message, and to define an > Extended Authentication Message that will strongly bind the HIT to a > group of messages by using the HI private key in a signature operation. > > More to follow. > > Bob > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------17D2F6BDE72AB906DB98831C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Oh, I left as one of this group's activities is using HIP for HIT registry with UAV management systems (e.g. UTMs).

Bob

On 9/23/19 12:05 PM, Robert Moskowitz wrote:
tm-rid members:

I will start this with a pointer to the current OpenDroneID spec (0.64.3):

https://www.opendroneid.org/

Code and other items are available at:

https://github.com/opendroneid

At the Symposium last week, a comment was made that this version is out to ballot to the ASTM members.  We have identified a few areas of concern on this version.  More on that later.

First, this messaging standard was developed to fit within the BT 4 “Beacon Advertisements” which effectively limits the messages to 25 bytes.  24 bytes are available to each OpenDroneID message.

Note that the BT 4 Beacon Advertisements include a 1 byte counter managed by the application (it seems).

Beacon Advertisements were chosen as these (it is claimed) are the only BT messages available to an application to send and receive that do not require pairing.  BT does not have an equivalent to IEEE 802.11OCB (at least for BT4).  BT4 itself was selected as the base transport to include the largest number of UAVs on the market.

Development platforms include:  UAVs, smartphones, tablets.

Further claimed that UAVs are in listen mode only.  These messages cannot be used by the ground to get specific information from the UAV.  I have problems believing this, but will use this limit for now.

Note that BT4 has a claimed range of 300M.  At 60MPH (~90KPM), the UAV will cover that range in ~11sec.  Beacon range MAY be longer due to their short size, much like 802.11 Beacons.

Further BT5 supports 255 bytes for Beacons.  This is important to know when you look at the Auth message size limit.

There are 5 messages defined in this draft.  I will discuss each.


Basic ID Message

We are going to work toward adding HIT as a standard ID type, per RFC 7401.  HHITs per draft-moskowitz-hip-hierarchical-hit will be an update to 7401, so I do not feel that OpenDrone spec needs to allocate a type for HHIT.

This message allows for 20 bytes for ID and has 3 bytes reserved.  I do not know anyway to authenticate this message within this limitation.  Give me 255 bytes and much can be done!  That may be in ver 2.0.  More on this later.


Location/Vector Message

Stuffed into the 24 byte limit.  Nothing can be added to this message.  The BAD thing about this message is what UAV is it from? You have a cluster of UAVs all sending these messages, they are close to useless.  If any message in this spec needs lengthening, this is it.  BT does have a 6 byte device? address.  Perhaps they are expecting this to be used, but it is not called out in the spec.


Authentication Message

This is defined as a static message.  That is it never changes for a flight.  We are calling for it to be dynamic, and Adam has a proposal to use this to authenticate a group of prior messages.  The HI private key will be used as the sig for our Extended Auth messages.  This will be discussed in a separate message and one of the important outputs of this effort.


Self ID Message

This is text about the UAV/mission.  23 bytes is not enough for many uses.  We are going to recommend this (like Auth), allow for extending to a max of 255 bytes.  At this point we are not thinking of adding signing to it, rather the Extended Auth message will cover it.


System Message

Similar issues as with Location/Vector.  Plus the UPS application has the GCS (the UPS truck!) moving rather rapidly so no slow updates to content for them.



This is a quick presentation of the OpenDroneID messages.  Our initial focus will be to place HITs in the Basic Message, and to define an Extended Authentication Message that will strongly bind the HIT to a group of messages by using the HI private key in a signature operation.

More to follow.

Bob


--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------17D2F6BDE72AB906DB98831C-- From nobody Mon Sep 23 10:30:01 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B47112004D for ; Mon, 23 Sep 2019 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-5bKO0V_zDB for ; Mon, 23 Sep 2019 10:29:55 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805C7120047 for ; Mon, 23 Sep 2019 10:29:55 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id n197so35406812iod.9 for ; Mon, 23 Sep 2019 10:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wlpbe+187MQ6ZJxdZd/vE0HNAsEOtxbRMMGjTIvxqj4=; b=u0eSLa/1TJPKqdDhaPW/IvQUs6Y5pjf2bxxXhhYyY0vbKVLEDYIqDJHbeehDW5Tx5o dgwNzdr/J2WAPahZjmS7bprKQT/ScGGH1pquHVLqb9MPp0vZLzy0t59nOSuv4VO5obHb t8J8qB4oPgv4WGE6SvFlYuc/fF8cez9HAaYIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wlpbe+187MQ6ZJxdZd/vE0HNAsEOtxbRMMGjTIvxqj4=; b=DClGGT1UF5g9kYQJbuQgodNfzEuq8iNLLffL4muUOB7ITN/thqKN/V/sV1CcsG01Y+ oSNQdargEzw6oSmGXBkSwAMo/seDZZUKeG08iklxJeCGX44gNaAEblM4T+m+klXaOQHc xyZNpHRdd14At9s11omN1AbQfnXSEUGQKFs00vnVGjKXt6CKzzxTsQ9MNxV34ULLtnl6 3yTKG37ouUY9ixSIVgOkqVmAvoEI3u4FxVZuOUXtUQpv+UWEOce0knh1SnO9p2kd9S2c Jh3z92p1Rj0y6fpyRqyiatQ71EqWxzJ4xCY+a9QcFHqhMrAwhS3EYRS3Anla6s9RG9S7 n1Ww== X-Gm-Message-State: APjAAAUmiLWYlP6WuzsEAgE8YY/6PeRPo4wsooi8vzYDuymuWqEmTYTf 8fx6rw42/QeT3tGgMggVV9LxdZ3mNrwgHn0H7w59cQ== X-Google-Smtp-Source: APXvYqw595mg5P+x1f8EYQUOpD/Z/s4lKNaPdjKQ4L0eIA8q+HorqUdEDR9DMquHFhvmXutJTU/umiVlJT+Wwsw3U8s= X-Received: by 2002:a6b:b704:: with SMTP id h4mr415364iof.218.1569259794548; Mon, 23 Sep 2019 10:29:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Card, Stu" Date: Mon, 23 Sep 2019 13:29:43 -0400 Message-ID: To: Robert Moskowitz Cc: tm-rid@ietf.org Content-Type: multipart/alternative; boundary="0000000000009d7efe05933bc415" Archived-At: Subject: Re: [Tm-rid] OpenDrone ID spec X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 17:29:59 -0000 --0000000000009d7efe05933bc415 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually the Unmanned Aircraft will only _transmit_, never receive, in Broadcast Remote ID, but the effect is the same: they cannot respond to queries that they would never hear. On Mon, Sep 23, 2019, 12:06 Robert Moskowitz wrote: > tm-rid members: > > I will start this with a pointer to the current OpenDroneID spec (0.64.3)= : > > https://www.opendroneid.org/ > > Code and other items are available at: > > https://github.com/opendroneid > > At the Symposium last week, a comment was made that this version is out > to ballot to the ASTM members. We have identified a few areas of > concern on this version. More on that later. > > First, this messaging standard was developed to fit within the BT 4 > =E2=80=9CBeacon Advertisements=E2=80=9D which effectively limits the mess= ages to 25 > bytes. 24 bytes are available to each OpenDroneID message. > > Note that the BT 4 Beacon Advertisements include a 1 byte counter > managed by the application (it seems). > > Beacon Advertisements were chosen as these (it is claimed) are the only > BT messages available to an application to send and receive that do not > require pairing. BT does not have an equivalent to IEEE 802.11OCB (at > least for BT4). BT4 itself was selected as the base transport to > include the largest number of UAVs on the market. > > Development platforms include: UAVs, smartphones, tablets. > > Further claimed that UAVs are in listen mode only. These messages > cannot be used by the ground to get specific information from the UAV. > I have problems believing this, but will use this limit for now. > > Note that BT4 has a claimed range of 300M. At 60MPH (~90KPM), the UAV > will cover that range in ~11sec. Beacon range MAY be longer due to > their short size, much like 802.11 Beacons. > > Further BT5 supports 255 bytes for Beacons. This is important to know > when you look at the Auth message size limit. > > There are 5 messages defined in this draft. I will discuss each. > > > Basic ID Message > > We are going to work toward adding HIT as a standard ID type, per RFC > 7401. HHITs per draft-moskowitz-hip-hierarchical-hit will be an update > to 7401, so I do not feel that OpenDrone spec needs to allocate a type > for HHIT. > > This message allows for 20 bytes for ID and has 3 bytes reserved. I do > not know anyway to authenticate this message within this limitation. > Give me 255 bytes and much can be done! That may be in ver 2.0. More > on this later. > > > Location/Vector Message > > Stuffed into the 24 byte limit. Nothing can be added to this message. > The BAD thing about this message is what UAV is it from? You have a > cluster of UAVs all sending these messages, they are close to useless. > If any message in this spec needs lengthening, this is it. BT does have > a 6 byte device? address. Perhaps they are expecting this to be used, > but it is not called out in the spec. > > > Authentication Message > > This is defined as a static message. That is it never changes for a > flight. We are calling for it to be dynamic, and Adam has a proposal to > use this to authenticate a group of prior messages. The HI private key > will be used as the sig for our Extended Auth messages. This will be > discussed in a separate message and one of the important outputs of this > effort. > > > Self ID Message > > This is text about the UAV/mission. 23 bytes is not enough for many > uses. We are going to recommend this (like Auth), allow for extending > to a max of 255 bytes. At this point we are not thinking of adding > signing to it, rather the Extended Auth message will cover it. > > > System Message > > Similar issues as with Location/Vector. Plus the UPS application has > the GCS (the UPS truck!) moving rather rapidly so no slow updates to > content for them. > > > > This is a quick presentation of the OpenDroneID messages. Our initial > focus will be to place HITs in the Basic Message, and to define an > Extended Authentication Message that will strongly bind the HIT to a > group of messages by using the HI private key in a signature operation. > > More to follow. > > Bob > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > --0000000000009d7efe05933bc415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually the Unmanned Aircraft will only _transmit_, neve= r receive, in Broadcast Remote ID, but the effect is the same: they cannot = respond to queries that they would never hear.

On Mon, Sep 23, 2019, 12:06 R= obert Moskowitz <rgm@labs.ht= t-consult.com> wrote:
tm-rid= members:

I will start this with a pointer to the current OpenDroneID spec (0.64.3):<= br>
https://www.opendroneid.org/

Code and other items are available at:

https://github.com/opendroneid

At the Symposium last week, a comment was made that this version is out to ballot to the ASTM members.=C2=A0 We have identified a few areas of
concern on this version.=C2=A0 More on that later.

First, this messaging standard was developed to fit within the BT 4
=E2=80=9CBeacon Advertisements=E2=80=9D which effectively limits the messag= es to 25
bytes.=C2=A0 24 bytes are available to each OpenDroneID message.

Note that the BT 4 Beacon Advertisements include a 1 byte counter
managed by the application (it seems).

Beacon Advertisements were chosen as these (it is claimed) are the only BT messages available to an application to send and receive that do not require pairing.=C2=A0 BT does not have an equivalent to IEEE 802.11OCB (at=
least for BT4).=C2=A0 BT4 itself was selected as the base transport to
include the largest number of UAVs on the market.

Development platforms include:=C2=A0 UAVs, smartphones, tablets.

Further claimed that UAVs are in listen mode only.=C2=A0 These messages cannot be used by the ground to get specific information from the UAV.=C2= =A0
I have problems believing this, but will use this limit for now.

Note that BT4 has a claimed range of 300M.=C2=A0 At 60MPH (~90KPM), the UAV=
will cover that range in ~11sec.=C2=A0 Beacon range MAY be longer due to their short size, much like 802.11 Beacons.

Further BT5 supports 255 bytes for Beacons.=C2=A0 This is important to know=
when you look at the Auth message size limit.

There are 5 messages defined in this draft.=C2=A0 I will discuss each.


Basic ID Message

We are going to work toward adding HIT as a standard ID type, per RFC
7401.=C2=A0 HHITs per draft-moskowitz-hip-hierarchical-hit will be an updat= e
to 7401, so I do not feel that OpenDrone spec needs to allocate a type
for HHIT.

This message allows for 20 bytes for ID and has 3 bytes reserved.=C2=A0 I d= o
not know anyway to authenticate this message within this limitation.=C2=A0 =
Give me 255 bytes and much can be done!=C2=A0 That may be in ver 2.0.=C2=A0= More
on this later.


Location/Vector Message

Stuffed into the 24 byte limit.=C2=A0 Nothing can be added to this message.= =C2=A0
The BAD thing about this message is what UAV is it from? You have a
cluster of UAVs all sending these messages, they are close to useless.=C2= =A0
If any message in this spec needs lengthening, this is it.=C2=A0 BT does ha= ve
a 6 byte device? address.=C2=A0 Perhaps they are expecting this to be used,=
but it is not called out in the spec.


Authentication Message

This is defined as a static message.=C2=A0 That is it never changes for a <= br> flight.=C2=A0 We are calling for it to be dynamic, and Adam has a proposal = to
use this to authenticate a group of prior messages.=C2=A0 The HI private ke= y
will be used as the sig for our Extended Auth messages.=C2=A0 This will be =
discussed in a separate message and one of the important outputs of this effort.


Self ID Message

This is text about the UAV/mission.=C2=A0 23 bytes is not enough for many <= br> uses.=C2=A0 We are going to recommend this (like Auth), allow for extending=
to a max of 255 bytes.=C2=A0 At this point we are not thinking of adding signing to it, rather the Extended Auth message will cover it.


System Message

Similar issues as with Location/Vector.=C2=A0 Plus the UPS application has =
the GCS (the UPS truck!) moving rather rapidly so no slow updates to
content for them.



This is a quick presentation of the OpenDroneID messages.=C2=A0 Our initial=
focus will be to place HITs in the Basic Message, and to define an
Extended Authentication Message that will strongly bind the HIT to a
group of messages by using the HI private key in a signature operation.

More to follow.

Bob

--
Tm-rid mailing list
Tm-= rid@ietf.org
https://www.ietf.org/mailman/listinfo/tm-rid<= /a>
--0000000000009d7efe05933bc415-- From nobody Mon Sep 23 14:16:08 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55F512022C for ; Mon, 23 Sep 2019 14:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXAqLZd1hF46 for ; Mon, 23 Sep 2019 14:16:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0290C12002E for ; Mon, 23 Sep 2019 14:16:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 503823897D for ; Mon, 23 Sep 2019 17:14:14 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7830BC6A for ; Mon, 23 Sep 2019 17:16:03 -0400 (EDT) From: Michael Richardson To: tm-rid@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Mon, 23 Sep 2019 17:16:03 -0400 Message-ID: <26234.1569273363@localhost> Archived-At: Subject: Re: [Tm-rid] OpenDrone ID spec X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 21:16:07 -0000 Card, Stu wrote: > Actually the Unmanned Aircraft will only _transmit_, never receive, in > Broadcast Remote ID, but the effect is the same: they cannot respond to > queries that they would never hear. That makes it hard to get freshness. Perhaps if they were allowed to listen to some other common source (low-bits of GPS signal, or some other signal), that could become a proxy for freshness. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Mon Sep 23 16:20:00 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEC8120088 for ; Mon, 23 Sep 2019 16:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzNoMoSuQrB0 for ; Mon, 23 Sep 2019 16:19:56 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5335E120045 for ; Mon, 23 Sep 2019 16:19:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E0B646210D; Mon, 23 Sep 2019 19:19:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1OaL4fEdARrz; Mon, 23 Sep 2019 19:19:46 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E06E0607A5; Mon, 23 Sep 2019 19:19:42 -0400 (EDT) To: Michael Richardson , tm-rid@ietf.org References: <26234.1569273363@localhost> From: Robert Moskowitz Message-ID: Date: Mon, 23 Sep 2019 19:19:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <26234.1569273363@localhost> Content-Type: multipart/alternative; boundary="------------08AEF9725034FD17DC82B994" Content-Language: en-US Archived-At: Subject: Re: [Tm-rid] OpenDrone ID spec X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 23:19:59 -0000 This is a multi-part message in MIME format. --------------08AEF9725034FD17DC82B994 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Most UAV have some other interface for the GCS (Ground Comm System) to talk to them.  These are highly unstandardized.  Sometimes just some RF control commands.  So potentially they do have a source of freshness. But in the ASTM standard, there is no need for freshness.  Oh there are time fields but they are in not absolute time, but and offset from something like start of flight time. The Extended Auth Message we are working on (I or Adam will post that soon) will have a 4byte timestamp that will need some approximation to real time.  But there are ways for the UAV to get that before it launches. On 9/23/19 5:16 PM, Michael Richardson wrote: > Card, Stu wrote: > > Actually the Unmanned Aircraft will only _transmit_, never receive, in > > Broadcast Remote ID, but the effect is the same: they cannot respond to > > queries that they would never hear. > > That makes it hard to get freshness. > > Perhaps if they were allowed to listen to some other common source (low-bits > of GPS signal, or some other signal), that could become a proxy for freshness. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------08AEF9725034FD17DC82B994 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Most UAV have some other interface for the GCS (Ground Comm System) to talk to them.  These are highly unstandardized.  Sometimes just some RF control commands.  So potentially they do have a source of freshness.

But in the ASTM standard, there is no need for freshness.  Oh there are time fields but they are in not absolute time, but and offset from something like start of flight time.

The Extended Auth Message we are working on (I or Adam will post that soon) will have a 4byte timestamp that will need some approximation to real time.  But there are ways for the UAV to get that before it launches.

On 9/23/19 5:16 PM, Michael Richardson wrote:
Card, Stu <stu.card@axenterprize.com> wrote:
    > Actually the Unmanned Aircraft will only _transmit_, never receive, in
    > Broadcast Remote ID, but the effect is the same: they cannot respond to
    > queries that they would never hear.

That makes it hard to get freshness.

Perhaps if they were allowed to listen to some other common source (low-bits
of GPS signal, or some other signal), that could become a proxy for freshness.

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



--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------08AEF9725034FD17DC82B994-- From nobody Wed Sep 25 14:40:17 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401CD12004E for ; Wed, 25 Sep 2019 14:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQMTjZNpgXqL for ; Wed, 25 Sep 2019 14:40:12 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDBD120018 for ; Wed, 25 Sep 2019 14:40:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7E138615EB for ; Wed, 25 Sep 2019 17:40:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UXUoafUlaBgo for ; Wed, 25 Sep 2019 17:40:04 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 46EF560029 for ; Wed, 25 Sep 2019 17:40:02 -0400 (EDT) References: <156944733678.29086.7089364498817707002.idtracker@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <156944733678.29086.7089364498817707002.idtracker@ietfa.amsl.com> Message-ID: <39be44d1-1f9b-6993-f302-1dd82cd50238@labs.htt-consult.com> Date: Wed, 25 Sep 2019 17:39:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <156944733678.29086.7089364498817707002.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------5BBF87B3E1CBE69F8C0EAE3A" Content-Language: en-US Archived-At: Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-01.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 21:40:15 -0000 This is a multi-part message in MIME format. --------------5BBF87B3E1CBE69F8C0EAE3A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit With this version, I believe I have the KEYMAT correct.  I had help from NIST and the Keccak team. It is MUCH more efficient than the HKDF or CKDF approaches. It is at least a solid starting point; we will see what other cryptographers say. I still need to work on the encryption part using Keyak. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hip-new-crypto-01.txt Date: Wed, 25 Sep 2019 14:35:36 -0700 From: internet-drafts@ietf.org To: Stuart Card , Adam Wiethuechter , Robert Moskowitz , Stuart W. Card A new version of I-D, draft-moskowitz-hip-new-crypto-01.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-new-crypto Revision: 01 Title: New Cryptographic Algorithms for HIP Document date: 2019-09-25 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-01.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-01 Abstract: This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------5BBF87B3E1CBE69F8C0EAE3A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit With this version, I believe I have the KEYMAT correct.  I had help from NIST and the Keccak team. It is MUCH more efficient than the HKDF or CKDF approaches.

It is at least a solid starting point; we will see what other cryptographers say.

I still need to work on the encryption part using Keyak.


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-new-crypto-01.txt
Date: Wed, 25 Sep 2019 14:35:36 -0700
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-new-crypto-01.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 01
Title: New Cryptographic Algorithms for HIP
Document date: 2019-09-25
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-01.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-01

Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------5BBF87B3E1CBE69F8C0EAE3A-- From nobody Fri Sep 27 07:53:56 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F09120819 for ; Fri, 27 Sep 2019 07:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8bOTW7x62fw for ; Fri, 27 Sep 2019 07:53:51 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4904120817 for ; Fri, 27 Sep 2019 07:53:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 84145615FA for ; Fri, 27 Sep 2019 10:53:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h+e35eMMyzCv for ; Fri, 27 Sep 2019 10:53:44 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 231AB60029 for ; Fri, 27 Sep 2019 10:53:44 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: <0fc9d954-a9af-b590-afb2-64ad2594f552@labs.htt-consult.com> Date: Fri, 27 Sep 2019 10:53:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Tm-rid] Draft charter X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 14:53:54 -0000 Here is my first attempt at a charter for tm-rid.  It will be up to our AD and HIP chairs if tm-rid is a standalone effort, or if this charter will be melded into a revised charter for additional HIP work. Here goes: The Federal Aviation Administration (FAA) Unmanned Aircraft Systems (UAS) Identification (ID) and Tracking Aviation Rulemaking Committee (ARC) (UAS-ID ARC) made recommendations to the FAA regarding technologies available for remote identification and tracking of UAS. The ARC recommended two modalities for remote identification, “broadcast” and “network”. “Broadcast” would require UAS to transmit information without bi-directional communication with a receiver. “Network” would require UAS to communicate information to a network such as UTM (Unmanned Aircraft Traffic Management). The ASTM (American Society for Testing and Materials) F38 Committee on UAS has been working on an industry consensus standard for Remote ID (RID) and Tracking, WK65041.  They have defined a set of messages for UAS to send over Bluetooth Beacon Advertisements or IEEE 802.11 Neighborhood Area Network (NAN) to meet the FAA requirements.  The Host Identity Tag (HIT) of HIP is ideally suited to work within this Boradcast RemoteID effort.  HITs can consolidate the 4-tuple of (UA ID, UA physical location, UA onboard host ID, UA onboard host logical location [IP address list]) to a 3-tuple (HIT, UA physical location, UA onboard host logical location). For HIP to be used effectively in this environment, it needs updates for: Hierarchical HITs (HHIT) to provide a direct registry of HITs.  HHIT was part of the original design of HIP, but was dropped for lack of a clear use case.  With HHITs, RemoteID messages containing HHITs will provide the information to use DNS to access information about the UAS. Expanded HIP Registration to support registration of a UAS HHIT in a Registry.  This registration process will provide proof of authenticity and prevent duplicate HHITs from occurring.  Further, these Registries will provide the UAS DNS information and other services (including, potentially, RVS for future FAA NetworkID effort). New cryptographic algorithms (e.g. EdDSA and Keccak functions) to meet the UAS constrained environment. Additionally, the ASTM RemoteID messages will be augmented for use with HIP.  Initially this will consist of additional RemoteID Authentication Messages that will use the HI in a public key signing operation to prove UAS ownership of the HHIT and provide ground-listeners proof of registration objects for safe UAS operation when ground-listeners do not have Internet access. Further work will emerge as experience is gained in using HIP for UAS RemoteID.  For example, some UTM systems envision using OATH for GCS (Ground Control Systems) and authorized safety personnel.  HIP as an OATH method may help in merging HIP into these systems. The goal is to complete these updates to HIP by the end of 2020. From nobody Fri Sep 27 09:37:22 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E97120A01 for ; Fri, 27 Sep 2019 09:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWn2jWhUNt-F for ; Fri, 27 Sep 2019 09:37:09 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F22A120A24 for ; Fri, 27 Sep 2019 09:37:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7887C615FA for ; Fri, 27 Sep 2019 12:37:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cbK8+mSqxBBY for ; Fri, 27 Sep 2019 12:36:51 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3B00E60029 for ; Fri, 27 Sep 2019 12:36:51 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: <1c0487eb-016e-5dbf-deb7-4fb7aeeb53e8@labs.htt-consult.com> Date: Fri, 27 Sep 2019 12:36:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Tm-rid] Adam's current extended auth message X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 16:37:21 -0000 I am sending this layout that Adam has been working on for people to get some idea of what we have been working on.  It needs fixes and details. It uses ECDSA-384 sigs of 96bytes.  I will be recommending EdDSA25519 sigs of 64 bytes. What goes into making the message hashes and how are they computed? For the later, i recommend SHAKE128 (or cSHAKE128). There is more, but I am short of time with Rosh Hashana Monday and Tuesday.  Here it is: =================================================================     |                        General Format                         | =================================================================     Page 0:      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+-------+-------+     |  Msg. Header  | # Hashes Left | STS-P | ETS-P | H-Alg | H-Len | +---------------+---------------+-------+-------+-------+-------+     |         Start Timestamp       |         End Timestamp         | +-------------------------------+-------------------------------+     |                Hash of Previous Auth. Message                 | +---------------------------------------------------------------+     |                Hash of Current Auth. Message                  | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     Msg. Header: (1 byte)         Defined by ASTM Remote ID Message protocol.         Bits 7-4: AuthType         Bits 3-0: Data Page         See https://github.com/opendroneid/specs, Message for more         details.     # Hashes Left: (1 byte)         A count of the number of hashes to be found in this Auth         message. This does not include the previous or current         Auth message hashes.         The first page will decrement this by 2 for the next page         in the sequence.     STS-P, ETS-P: (4 bits), (4 bits)         This is a precision value for the Start and End timestamps         respectively.         See ASTM draft, Figure 3; Timestamp/Speed Accuracy field         for details. We are only concered about bits 7-4.     H-Alg, H-Len: (4 bits), (4 bits)         These are fields for relaying information of the Hash         algorithm used for the messages and the Hash length (in octets).         For this example of the format a length of 4 bytes is         used.     Start Timestamp: (2 bytes)         Time stamp dictating that messages hashed in this Auth         message came after this specified time, but NOT after         End Timestamp.         See ASTM draft for Timestamp format details.     End Timestamp: (2 bytes)         Time stamp dictating that messages hashed in this Auth         message came before this specified time, but NOT before         Start Timestamp.         See ASTM draft for Timestamp format details.     Hash of Previous Auth. Message: (4 bytes)         A hash of the previous send Auth message.     Hash of Current Auth. Message: (4 bytes)         A hash of the current Auth message.         A few notes on this field:         a) First during creation and signing of this message format         this field MUST be set to 0. So the signature will be         based on this field being 0, as well as its own hash. It         is an open question of if we compute the hash, then sign         or sign then compute.         b) There a few different ways to cycle this message. We can         "roll up" the hash of 'current' to 'previous' when needed         or to completely recompute the hash. This mostly depends on         the previous note.     Message Hash: (4 bytes)         A hash of a previously sent message. ===============================================================================     Page 1 to N (N<=11):      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |  Msg. Header  | # Hashes Left | RESERVED           | +---------------+---------------+-------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     Msg. Header: (1 byte)         Defined by ASTM Remote ID Message protocol.         Bits 7-4: AuthType         Bits 3-0: Data Page         See https://github.com/opendroneid/specs, Message for more         details.     # Hashes Left: (1 byte)         A count of the number of hashes to be found left in this         Auth message.         Every full page of hashes will decrement this by 5 until it         reaches 0 (which signals the end of hashes and start of         the Auth message signature).         If a page has less than 5 hashes then the rest of the page         should be padded with zeros.     Message Hash: (4 bytes)         A hash of a previously sent message. ==========================================================================     Page N to K (N<=11 && K<=15):      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |  Msg. Header  | # Hashes Left | RESERVED           | +---------------+---------------+-------------------------------+     |            Length             |      Signature Algorithm      | +-------------------------------+-------------------------------+ |                                                               | |                                                               | |                                                               |     |                         HIP Signature                         | |                                                               | |                                                               | |                                                               | +---------------------------------------------------------------+     Msg. Header: (1 byte)         Defined by ASTM Remote ID Message protocol.         Bits 7-4: AuthType         Bits 3-0: Data Page         See https://github.com/opendroneid/specs, Message for more         details.     # Hashes Left: (1 byte)         A count of the number of hashes to be found in this Auth         message. This does not include the previous or current         Auth message hashes.         For this page (and all subsequent pages) it SHOULD be 0.     Length: (2 bytes)         length is octets, excluding Length, and Padding     Signature Algoirthm: (2 bytes)         Self explanatory.     HIP Signature: (96 bytes)         Based on ECDSA-384 Signature.         If smaller HIT based signature is used then more hashes can fit         into the full message format across the 16 pages. With a         ECDSA-384 signature a maximum of 64 message hashes can be sent.         23 bytes per page * 16 pages = 368 bytes         - 96 bytes for sig = 272 bytes         - 8 bytes for timestamps = 264 bytes         - 8 bytes for auth message hashs = 256 bytes         / 4 bytes per hash = 64 hashes         See RFC4754 for detail on ECDSA-384 and RFC7401 on HIPs use of         ECDSA for HI/HIT.         If the end of the signature does not fill a full page, it         WILL be padded with zeros at the end. ============================================================================     Page 0:      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+-------+-------+     |  Msg. Header  | # Hashes Left | STS-P | ETS-P | H-Alg | H-Len | +---------------+---------------+-------+-------+-------+-------+     |         Start Timestamp       |         End Timestamp         | +-------------------------------+-------------------------------+     |                Hash of Previous Auth. Message                 | +---------------------------------------------------------------+     |                Hash of Current Auth. Message                  | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     Page 1 to N (N<=11):      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |  Msg. Header  | # Hashes Left | RESERVED           | +---------------+---------------+-------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     Page N to K (N<=11 && K<=15):      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |  Msg. Header  | # Hashes Left | RESERVED           | +---------------+---------------+-------------------------------+     |            Length             |      Signature Algorithm      | +-------------------------------+-------------------------------+ |                                                               | |                                                               | |                                                               |     |                         HIP Signature                         | |                                                               | |                                                               | |                                                               | +---------------------------------------------------------------+ ============================================================================     DETAILED EXAMPLE OF FULL AUTH MESSAGE FORMAT =================================================================     |                         AUTH PAGE 0                           | =================================================================      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+-------+-------+     |0 0 0 1 0 0 0 0|0 0 1 1 0 1 0 0| STS-P | ETS-P | H-Alg |0 1 0 0| +---------------+---------------+-------+-------+-------+-------+     |         Start Timestamp       |         End Timestamp         | +-------------------------------+-------------------------------+     |                Hash of Previous Auth. Message                 | +---------------------------------------------------------------+     |                Hash of Current Auth. Message                  | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+ =================================================================     |                         AUTH PAGE 1                           | =================================================================      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |0 0 0 1 0 0 0 1|0 0 1 1 0 0 1 0| RESERVED           | +---------------+---------------+-------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+ =================================================================     |                         AUTH PAGE 2 - 9                       | =================================================================      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |0 0 0 1 0 0 1 0|0 0 0 0 0 1 0 1| RESERVED           | +---------------+---------------+-------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |0 0 0 1 1 0 0 1|0 0 0 0 0 1 0 1| RESERVED           | +---------------+---------------+-------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+ =================================================================     |                         AUTH PAGE 10                          | =================================================================      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |0 0 0 1 1 0 1 0|0 0 0 0 0 0 0 0| RESERVED           | +---------------+---------------+-------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+     |                          Message Hash                         | +---------------------------------------------------------------+ =================================================================     |                    AUTH PAGE 11 - 15 (Signature)              | =================================================================      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+     |0 0 0 1 1 0 1 1|0 0 0 0 0 0 0 0| RESERVED           | +---------------+---------------+-------------------------------+     |            Length             |      Signature Algorithm      | +-------------------------------+-------------------------------+ |                                                               | |                                                               | |                                                               |     |                         HIP Signature                         | |                                                               | |                                                               | |                                                               | +---------------------------------------------------------------+      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-----------------------------------------------+     |0 0 0 1 1 1 0 0|                                               | +---------------+                                               | |                                                               | |                                                               | |                                                               | |                                                               |     |                         HIP Signature                         | |                                                               | |                                                               | |                                                               | |                                                               | +---------------------------------------------------------------+      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-----------------------------------------------+     |0 0 0 1 1 1 0 1|                                               | +---------------+                                               | |                                                               | |                                                               | |                                                               | |                                                               |     |                         HIP Signature                         | |                                                               | |                                                               | |                                                               | |                                                               | +---------------------------------------------------------------+      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-----------------------------------------------+     |0 0 0 1 1 1 1 0|                                               | +---------------+                                               | |                                                               | |                                                               | |                                                               | |                                                               |     |                         HIP Signature                         | |                                                               | |                                                               | |                                                               | |                                                               | +---------------------------------------------------------------+      0                   1                   2 3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-----------------------------------------------+     |0 0 0 1 1 1 1 1|                                               | +---------------+                                               |     |                         HIP Signature                         | |                                                               | |                                                               | +---------------------------------------------------------------+ |                                                               | |                                                               |     | Padding                            | |                                                               | |                                                               | +---------------------------------------------------------------+ From nobody Fri Sep 27 09:40:43 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8B01209C4 for ; Fri, 27 Sep 2019 09:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBuTN6AaMyGp for ; Fri, 27 Sep 2019 09:40:38 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58841209C0 for ; Fri, 27 Sep 2019 09:40:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CEDF8615FA for ; Fri, 27 Sep 2019 12:40:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gwhJIDcDKJZ6 for ; Fri, 27 Sep 2019 12:40:30 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B3A7460029 for ; Fri, 27 Sep 2019 12:40:28 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: Date: Fri, 27 Sep 2019 12:40:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Tm-rid] HHIT trust proof for Auth messages X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 16:40:41 -0000 And here is something I have been working on as condensed proof of HHIT ownership objects that can be put into the auth messages.  I have not done that yet, like Adam has:    
           0                   1 2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                               |   | HHIT                              | |                                                               | |                                                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | TIMESTAMP                          | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                               |   | HHIT                              |   | SIG                              | .                                                               . .                                                               . .                                                               . |                                                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   / PAYLOAD                            / /                                                               /   / +-------------------------------+   / |                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   HHIT           16 byte HHIT of EdDSA25519 HI   TIMESTAMP      4 byte packet trust until timestamp   HHIT SIG       64 byte Signature of whole packet   PAYLOAD        0 to n bytes of payload       Length     84 + n bytes            
   
           0                   1 2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                               |   |                            DEV HHIT                           | |                                                               | |                                                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | TIMESTAMP                          | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                               |   |                            DEV HHIT                           |   | SIG                              | .                                                               . .                                                               . .                                                               . |                                                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                               |   |                              DEV HI                           | |                                                               | |                                                               | |                                                               | |                                                               | |                                                               | |                                                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                         AUTH TIMESTAMP                        | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                               |   |                           AUTH HHIT                           | |                                                               | |                                                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                               |   | AUTH                               |   | SIG                              | .                                                               . .                                                               . .                                                               . |                                                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   / PAYLOAD                            / /                                                               /   / +-------------------------------+   / |                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   DEV HHIT       16 byte Dev HHIT of EdDSA25519 HI   TIMESTAMP      4 byte packet trust until timestamp   DEV HHIT SIG   64 byte Signature of whole packet   DEV HI         32 byte Device HI of EdDSA25519 HI   AUTH TIMESTAMP 4 byte Dev HHIT trust until timestamp   AUTH HHIT      16 byte Authorizer's HHIT of EdDSA25519 HI   AUTH SIG       64 byte Signature of Device HHIT-HI   PAYLOAD        0 to n bytes of payload       Length    200 + n bytes            
  |             Type              | Length            | From nobody Fri Sep 27 12:33:19 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94A120116 for ; Fri, 27 Sep 2019 12:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1z6yFNFYJgoJ for ; Fri, 27 Sep 2019 12:33:14 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA69F1200E6 for ; Fri, 27 Sep 2019 12:33:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 74739615FA for ; Fri, 27 Sep 2019 15:33:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v02Ai2vKRgil for ; Fri, 27 Sep 2019 15:33:10 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A879B60029 for ; Fri, 27 Sep 2019 15:33:08 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: Date: Fri, 27 Sep 2019 15:33:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Tm-rid] Hackathon planning X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 19:33:18 -0000 It would be good if we can have a hackathon event.  The goal would be to get UAV (or simulated UAV) broadcasting to ground devices. The goal for IETF106 is to get familiar with the technology and thus direct draft development. 3 parts to the puzzle: UAV supporting RemoteID with HIP enhancements Ground devices receiving broadcasts Infrastructure providing static information about UAV UAV supporting RemoteID with HIP enhancements Actual UAV or the microcontrollers used in UAV with software to broadcast all 5 ASTM messages.  The Authentication Messages will be augmented with the HI signing.  This will be over all 3 RF defined: BT4, BT5, WiFi NAN. I have seen one report that NAN support is basically not there in smartphones.  One tester has switched to using WiFi BEACONs, as I get more information and pointers to this, we will look at this as a serious alternative to NAN. We may need to 'cheat' at the GPS information in the Location/Vector Message to make for good testing. Ground devices receiving broadcasts Platforms are smartphones (iPhones and Android), tables (same), Linux and Windows notebooks.  They receive the broadcasts, access network information based on RemoteID in Basic Message and present information in a map. Infrastructure providing static information about UAV DNS and other services.  HIP Registry service with DNS query support. That is it in brief.  Who is interested?  I will be in a nearby hotel for my Sabbath that I can easily walk over Saturday evening and will be moving to the Stamford Sunday morning. Bob From nobody Mon Sep 30 22:33:23 2019 Return-Path: X-Original-To: tm-rid@ietfa.amsl.com Delivered-To: tm-rid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279EE12002E; Mon, 30 Sep 2019 22:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Vbz1JHd/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vm8I+0q1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBzvlu8kH9SQ; Mon, 30 Sep 2019 22:33:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9F9120044; Mon, 30 Sep 2019 22:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5232; q=dns/txt; s=iport; t=1569907999; x=1571117599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2qsBVS9y73ja/iBOwbMDz5Skt40hI69dfl9uL7/CEFc=; b=Vbz1JHd/8fqLcxIBpusYn0btyDP5KVrW7kmKqRbdWfRIwOVLJaPEDmu+ Rd4vn7v8WzBzToUebZypeKYg0tEwr7sUocTBoh6zY9XYK7zM+7Pm9b3GB xV3JEXiIZWA/UEDlQsGDEGuaBSjDq8X/EyKruzesyJx5SG74bB8Kxdrpu I=; IronPort-PHdr: =?us-ascii?q?9a23=3A8PrbcR9/AYA81/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcObGEvwL/PCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAACG5JJd/4cNJK1cCRoBAQEBAQI?= =?us-ascii?q?BAQEBDAIBAQEBgWeBSyQsA21WIAQLKoQig0cDil6CN5gcgUKBEANUCQEBAQw?= =?us-ascii?q?BARgLCgIBAYRAAheDLiM4EwIDCQEBBAEBAQIBBQRthS0MhUwCBAEBEBERDAE?= =?us-ascii?q?BKgILAQ8CAQgODAImAgICJQsVEAIEAQ0FIoMAAYFqAx0BAgyjOQKBOIhhdYE?= =?us-ascii?q?ygn0BAQWCSYI8GIIXAwaBDCiMDhiBQD+BEScME4JMPoJhAQGBJRIqF4J2MoI?= =?us-ascii?q?mjGCDB4dklG5uCoIihwaOChuZOI4jiBqRDQIEAgQFAg4BAQWBaSKBWHAVOyo?= =?us-ascii?q?BgkFQEBRWeQwXg1CFFIU/dAGBKI1EBIJQAQE?= X-IronPort-AV: E=Sophos;i="5.64,570,1559520000"; d="scan'208";a="633834764" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2019 05:33:18 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x915XIRT020719 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Oct 2019 05:33:18 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct 2019 00:33:18 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct 2019 00:33:16 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 1 Oct 2019 01:33:16 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mLHzN0eB0S/DOwJvXCvbPV5BYc1K05ydeE3GX7bZ7nlG0HR9IWUeDkLAZTTkyn27xsaf0dzXpPfwHqDOBHphT0GiuXdoOHG9eOE+275MvWk+FugVZrnsBqMGu4SRiF/ue6fqSq2oekkgrzwSELGOEn/84KxM5dett29e1c2LJr9A+QFmcdUAR3kvkvvSTKM8XJaD1OoHERrZsaCCLJsmydIYeXfgihJOVWq/KuPw21b41BxqDacOF6MFtkrpWL/IedIM8K1pByDI14wA+WmSfcEcjEbLEaXfH42+ivHUA+rN2vLAxOakh6GAQAO1Rl0G8O4bR5NR2mYJEL7peQHcVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2qsBVS9y73ja/iBOwbMDz5Skt40hI69dfl9uL7/CEFc=; b=cjoBzmZ17hwC7LqD1MO6yloA31Gw1O3unnGpEfnl6EAu803ZkANIUkTAwNYUew2IA54qxit3KgCECM53bIkwUGxqgcumlXcu1dlQOjYgIgS6Mk7vOSLnthWJ5vjG7RtGrTbLOFiYpAcA4X8NL2l9qbSA9hfxpVsbnq1oq+uT7twhyP4S46oPX2b7pN6ZpvF22u9SX6kZCu+53Ke42OpgZV5sfLcTz54h3pdVCt/Ozg7d2r9Wc2VhgpAdaIXWPO1BaC8jN3tixtd6bcITmoSXNOuBpkdEuRl7PVwttzLSTMGOWV+VN6mWAdFirgGgi+VtJDZDATxrkwJBf1Ko/cyVaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2qsBVS9y73ja/iBOwbMDz5Skt40hI69dfl9uL7/CEFc=; b=vm8I+0q1ALsC9eq/ZFvIwMYeqnN395RWL1ET2uarbjMJqa/ZdJftkBQUeOYcDllLJhj5MMkBXwmKMWayvrxGNHtNyY7KHM2CwxqMxbxUH+nQqTPQQI+TwTsiDE4yHAPyvukL/cbg1b0SwLNF3JyM+kZ+Oe0jHrnJ1e9MWUzYLxs= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3775.namprd11.prod.outlook.com (20.178.253.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Tue, 1 Oct 2019 05:33:15 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2305.022; Tue, 1 Oct 2019 05:33:15 +0000 From: "Eric Vyncke (evyncke)" To: Robert Moskowitz , "tm-rid@ietf.org" CC: "hipsec@ietf.org" Thread-Topic: [Tm-rid] Draft charter Thread-Index: AQHVdUNvnNd8vCGuaUOEPASXQD5/WKdFezQA Date: Tue, 1 Oct 2019 05:33:15 +0000 Message-ID: <044840A0-85DF-4382-8983-1FC563A53F11@cisco.com> References: <0fc9d954-a9af-b590-afb2-64ad2594f552@labs.htt-consult.com> In-Reply-To: <0fc9d954-a9af-b590-afb2-64ad2594f552@labs.htt-consult.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:3dbd:81a9:b466:77ee] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f5bf68aa-417c-47f0-12af-08d74630dbdd x-ms-traffictypediagnostic: MN2PR11MB3775: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(136003)(366004)(376002)(396003)(199004)(189003)(25786009)(478600001)(33656002)(5660300002)(966005)(6116002)(8676002)(2616005)(316002)(486006)(66574012)(446003)(81166006)(81156014)(6486002)(99286004)(11346002)(6306002)(6436002)(6512007)(6246003)(476003)(46003)(229853002)(58126008)(14454004)(186003)(76176011)(110136005)(8936002)(102836004)(305945005)(71200400001)(4326008)(36756003)(2906002)(76116006)(66476007)(7736002)(2501003)(71190400001)(91956017)(66946007)(66446008)(64756008)(86362001)(256004)(6506007)(66556008)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3775; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4XhimQpXVUNdrY7SOfxoMI57DZID+OuqyNq9uo4myOa5q0IzsYBewD/lY5DgRjZyGV2jHqeWnerZonJRXPyBXDJ3ApZSjTyczitCD11NasqSjleMo8t+N6iEXxa2RYBzmJ759kE8i9/oxZkNNJYLszDFObER2B3+WC3ooQQt30MFlJn9zelcsxEVkl5VuSMl24oWDcppDh5ffJh5ii0kXvPZjSEcYgo5jeb8zHgovs/vwoz0xCSEseCDVR6L+X8vOPlDrOYwVEuzX7xVeS3l72+4jAmBL9e5PR6YJIdmWFaEft6DElUHPWe6pm/n6zdK2tBIKlMSlF55tX/knWbLnZdKa+MswfucWMz6GU7gpQaM2REqcSx3RmAEEKxQlDMaZQiu5L7/Nj4SiaHp9hKA58refljDsl+K2GJvdvTyr4dbwjipNz+MaPZNjga7CjRWhKAO/Y702xPEc1S/dAy2Ow== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <301DA087C80E5B4C9604C830EF87C7FF@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f5bf68aa-417c-47f0-12af-08d74630dbdd X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 05:33:15.6847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pt6oiNSFawKQp9Kd3RYznJqIe6RW4Wah31mSZkvXFl2cNBwIxjgpA6BsvzrRnnnPhGDkv8DC96tCpWn8bo6sEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3775 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Tm-rid] Draft charter X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Trustworthy Multipurpose RemoteID List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 05:33:22 -0000 Qm9iLA0KDQpKdXN0IHRvIHBsYXkgaXQgb24gdGhlIHNhZmUgc2lkZSwgY2FuIHlvdSBzY2hlZHVs ZSBhIFRNLVJJRCBCb0YgYXQgU2luZ2Fwb3JlIHZpYSBodHRwczovL3RyYWMudG9vbHMuaWV0Zi5v cmcvYm9mL3RyYWMvID8gRGVhZGxpbmUgaXMgRnJpZGF5IDR0aCBvZiBPY3RvYmVyIGFuZCB0aGUg Qm9GIGNvdWxkIGVhc2lseSBiZSBjYW5jZWxsZWQgaWYgSElQIGlzIG1lZXRpbmcgd2l0aCBhbiBl eHRlbmRlZCBjaGFydGVyLg0KDQotw6lyaWMNCg0K77u/T24gMjcvMDkvMjAxOSwgMTY6NTQsICJU bS1yaWQgb24gYmVoYWxmIG9mIFJvYmVydCBNb3Nrb3dpdHoiIDx0bS1yaWQtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgcmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tPiB3cm90ZToNCg0KICAg IEhlcmUgaXMgbXkgZmlyc3QgYXR0ZW1wdCBhdCBhIGNoYXJ0ZXIgZm9yIHRtLXJpZC4gIEl0IHdp bGwgYmUgdXAgdG8gb3VyIA0KICAgIEFEIGFuZCBISVAgY2hhaXJzIGlmIHRtLXJpZCBpcyBhIHN0 YW5kYWxvbmUgZWZmb3J0LCBvciBpZiB0aGlzIGNoYXJ0ZXIgDQogICAgd2lsbCBiZSBtZWxkZWQg aW50byBhIHJldmlzZWQgY2hhcnRlciBmb3IgYWRkaXRpb25hbCBISVAgd29yay4NCiAgICANCiAg ICBIZXJlIGdvZXM6DQogICAgDQogICAgVGhlIEZlZGVyYWwgQXZpYXRpb24gQWRtaW5pc3RyYXRp b24gKEZBQSkgVW5tYW5uZWQgQWlyY3JhZnQgU3lzdGVtcyANCiAgICAoVUFTKSBJZGVudGlmaWNh dGlvbiAoSUQpIGFuZCBUcmFja2luZyBBdmlhdGlvbiBSdWxlbWFraW5nIENvbW1pdHRlZSANCiAg ICAoQVJDKSAoVUFTLUlEIEFSQykgbWFkZSByZWNvbW1lbmRhdGlvbnMgdG8gdGhlIEZBQSByZWdh cmRpbmcgDQogICAgdGVjaG5vbG9naWVzIGF2YWlsYWJsZSBmb3IgcmVtb3RlIGlkZW50aWZpY2F0 aW9uIGFuZCB0cmFja2luZyBvZiBVQVMuIA0KICAgIFRoZSBBUkMgcmVjb21tZW5kZWQgdHdvIG1v ZGFsaXRpZXMgZm9yIHJlbW90ZSBpZGVudGlmaWNhdGlvbiwgDQogICAg4oCcYnJvYWRjYXN04oCd IGFuZCDigJxuZXR3b3Jr4oCdLg0KICAgIA0KICAgIOKAnEJyb2FkY2FzdOKAnSB3b3VsZCByZXF1 aXJlIFVBUyB0byB0cmFuc21pdCBpbmZvcm1hdGlvbiB3aXRob3V0IA0KICAgIGJpLWRpcmVjdGlv bmFsIGNvbW11bmljYXRpb24gd2l0aCBhIHJlY2VpdmVyLiDigJxOZXR3b3Jr4oCdIHdvdWxkIHJl cXVpcmUgDQogICAgVUFTIHRvIGNvbW11bmljYXRlIGluZm9ybWF0aW9uIHRvIGEgbmV0d29yayBz dWNoIGFzIFVUTSAoVW5tYW5uZWQgDQogICAgQWlyY3JhZnQgVHJhZmZpYyBNYW5hZ2VtZW50KS4N CiAgICANCiAgICBUaGUgQVNUTSAoQW1lcmljYW4gU29jaWV0eSBmb3IgVGVzdGluZyBhbmQgTWF0 ZXJpYWxzKSBGMzggQ29tbWl0dGVlIG9uIA0KICAgIFVBUyBoYXMgYmVlbiB3b3JraW5nIG9uIGFu IGluZHVzdHJ5IGNvbnNlbnN1cyBzdGFuZGFyZCBmb3IgUmVtb3RlIElEIA0KICAgIChSSUQpIGFu ZCBUcmFja2luZywgV0s2NTA0MS4gIFRoZXkgaGF2ZSBkZWZpbmVkIGEgc2V0IG9mIG1lc3NhZ2Vz IGZvciANCiAgICBVQVMgdG8gc2VuZCBvdmVyIEJsdWV0b290aCBCZWFjb24gQWR2ZXJ0aXNlbWVu dHMgb3IgSUVFRSA4MDIuMTEgDQogICAgTmVpZ2hib3Job29kIEFyZWEgTmV0d29yayAoTkFOKSB0 byBtZWV0IHRoZSBGQUEgcmVxdWlyZW1lbnRzLiAgVGhlIEhvc3QgDQogICAgSWRlbnRpdHkgVGFn IChISVQpIG9mIEhJUCBpcyBpZGVhbGx5IHN1aXRlZCB0byB3b3JrIHdpdGhpbiB0aGlzIA0KICAg IEJvcmFkY2FzdCBSZW1vdGVJRCBlZmZvcnQuICBISVRzIGNhbiBjb25zb2xpZGF0ZSB0aGUgNC10 dXBsZSBvZiAoVUEgSUQsIA0KICAgIFVBIHBoeXNpY2FsIGxvY2F0aW9uLCBVQSBvbmJvYXJkIGhv c3QgSUQsIFVBIG9uYm9hcmQgaG9zdCBsb2dpY2FsIA0KICAgIGxvY2F0aW9uIFtJUCBhZGRyZXNz IGxpc3RdKSB0byBhIDMtdHVwbGUgKEhJVCwgVUEgcGh5c2ljYWwgbG9jYXRpb24sIFVBIA0KICAg IG9uYm9hcmQgaG9zdCBsb2dpY2FsIGxvY2F0aW9uKS4NCiAgICANCiAgICBGb3IgSElQIHRvIGJl IHVzZWQgZWZmZWN0aXZlbHkgaW4gdGhpcyBlbnZpcm9ubWVudCwgaXQgbmVlZHMgdXBkYXRlcyBm b3I6DQogICAgDQogICAgSGllcmFyY2hpY2FsIEhJVHMgKEhISVQpIHRvIHByb3ZpZGUgYSBkaXJl Y3QgcmVnaXN0cnkgb2YgSElUcy4gIEhISVQgd2FzIA0KICAgIHBhcnQgb2YgdGhlIG9yaWdpbmFs IGRlc2lnbiBvZiBISVAsIGJ1dCB3YXMgZHJvcHBlZCBmb3IgbGFjayBvZiBhIGNsZWFyIA0KICAg IHVzZSBjYXNlLiAgV2l0aCBISElUcywgUmVtb3RlSUQgbWVzc2FnZXMgY29udGFpbmluZyBISElU cyB3aWxsIHByb3ZpZGUgDQogICAgdGhlIGluZm9ybWF0aW9uIHRvIHVzZSBETlMgdG8gYWNjZXNz IGluZm9ybWF0aW9uIGFib3V0IHRoZSBVQVMuDQogICAgDQogICAgRXhwYW5kZWQgSElQIFJlZ2lz dHJhdGlvbiB0byBzdXBwb3J0IHJlZ2lzdHJhdGlvbiBvZiBhIFVBUyBISElUIGluIGEgDQogICAg UmVnaXN0cnkuICBUaGlzIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIHdpbGwgcHJvdmlkZSBwcm9vZiBv ZiBhdXRoZW50aWNpdHkgDQogICAgYW5kIHByZXZlbnQgZHVwbGljYXRlIEhISVRzIGZyb20gb2Nj dXJyaW5nLiAgRnVydGhlciwgdGhlc2UgUmVnaXN0cmllcyANCiAgICB3aWxsIHByb3ZpZGUgdGhl IFVBUyBETlMgaW5mb3JtYXRpb24gYW5kIG90aGVyIHNlcnZpY2VzIChpbmNsdWRpbmcsIA0KICAg IHBvdGVudGlhbGx5LCBSVlMgZm9yIGZ1dHVyZSBGQUEgTmV0d29ya0lEIGVmZm9ydCkuDQogICAg DQogICAgTmV3IGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyAoZS5nLiBFZERTQSBhbmQgS2VjY2Fr IGZ1bmN0aW9ucykgdG8gbWVldCANCiAgICB0aGUgVUFTIGNvbnN0cmFpbmVkIGVudmlyb25tZW50 Lg0KICAgIA0KICAgIEFkZGl0aW9uYWxseSwgdGhlIEFTVE0gUmVtb3RlSUQgbWVzc2FnZXMgd2ls bCBiZSBhdWdtZW50ZWQgZm9yIHVzZSB3aXRoIA0KICAgIEhJUC4gIEluaXRpYWxseSB0aGlzIHdp bGwgY29uc2lzdCBvZiBhZGRpdGlvbmFsIFJlbW90ZUlEIEF1dGhlbnRpY2F0aW9uIA0KICAgIE1l c3NhZ2VzIHRoYXQgd2lsbCB1c2UgdGhlIEhJIGluIGEgcHVibGljIGtleSBzaWduaW5nIG9wZXJh dGlvbiB0byBwcm92ZSANCiAgICBVQVMgb3duZXJzaGlwIG9mIHRoZSBISElUIGFuZCBwcm92aWRl IGdyb3VuZC1saXN0ZW5lcnMgcHJvb2Ygb2YgDQogICAgcmVnaXN0cmF0aW9uIG9iamVjdHMgZm9y IHNhZmUgVUFTIG9wZXJhdGlvbiB3aGVuIGdyb3VuZC1saXN0ZW5lcnMgZG8gbm90IA0KICAgIGhh dmUgSW50ZXJuZXQgYWNjZXNzLg0KICAgIA0KICAgIEZ1cnRoZXIgd29yayB3aWxsIGVtZXJnZSBh cyBleHBlcmllbmNlIGlzIGdhaW5lZCBpbiB1c2luZyBISVAgZm9yIFVBUyANCiAgICBSZW1vdGVJ RC4gIEZvciBleGFtcGxlLCBzb21lIFVUTSBzeXN0ZW1zIGVudmlzaW9uIHVzaW5nIE9BVEggZm9y IEdDUyANCiAgICAoR3JvdW5kIENvbnRyb2wgU3lzdGVtcykgYW5kIGF1dGhvcml6ZWQgc2FmZXR5 IHBlcnNvbm5lbC4gIEhJUCBhcyBhbiANCiAgICBPQVRIIG1ldGhvZCBtYXkgaGVscCBpbiBtZXJn aW5nIEhJUCBpbnRvIHRoZXNlIHN5c3RlbXMuDQogICAgDQogICAgVGhlIGdvYWwgaXMgdG8gY29t cGxldGUgdGhlc2UgdXBkYXRlcyB0byBISVAgYnkgdGhlIGVuZCBvZiAyMDIwLg0KICAgIA0KICAg IA0KICAgIC0tIA0KICAgIFRtLXJpZCBtYWlsaW5nIGxpc3QNCiAgICBUbS1yaWRAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RtLXJpZA0KICAgIA0K DQo=