Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt

[Robert Moskowitz <[e-mail]>]

On 10/21/21 2:40 AM, [e-mail] wrote:
> Hi Robert,
>
> Thank you for addressing the comment from the cfrg, particularly this one: https://mailarchive.ietf.org/arch/msg/cfrg/tAJJq60W6TlUv7_pde5cw5TDTCU/
> BTW, please check the 2nd line of the third paragraph of the new text about pre-image attack as I'm not sure to parse it.
>
> Also, it could be great if you can motivate the change in the normative language in Section 4.2. Thank you.

I believe this is about the MUSTs in:

     The low-order 68 bits (HIT Suite ID | ORCHID hash) of the HHIT
     SHALL be left-padded with 2 bits of ZERO.  This 70 bit number will
     be encoded into 14 characters using the digit/letters above. The
     manufacturer MUST use a Length Code of F (15).  The first character
     after the Length Code MUST be 'Z', followed by the 14 characters of
     the encoded HIT Suite ID and ORCHID hash.

At first I was allowing either for a Length Code of E or F and if F then 
choose what you want for the first character of the MFR SN field.

Then I considered the other side:  the observer that will be parsing 
this CTA SN.

How to at least hint to the receiver that the CTA SN MAY be an encoded 
HHIT and either watch for a Authentication Message to directly prove it 
or look up (in some yet to be defined service) the MFR CODE to see if it 
points to a HHIT PREFIX|HID.

So I realized I needed to strongly restrict the encoding rules to 
facilitate the receiver processing.  That 'FZ' provides the hint to the 
receiver that this CTA SN MAY be an encoded HHIT.

Of course we can use ANY of the 34 allowed characters, I chose 'Z' with 
no explanation.

Note that at first I wrote it with SHOULD, but that still leaves it up 
to the sender with resultant impact on the receiver.  So I used MUST.




> All: please review and share your comments. This is highly appreciated.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Tm-rid <[e-mail]> De la part de Robert Moskowitz
>> Envoyé : mercredi 20 octobre 2021 22:19
>> À : [e-mail]
>> Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt
>>
>> Changes in sec 4.2 and 11.  Please review.
>>
>> Adam and I are discussing sec 5, as he actually has done some
>> implementation demos and I may make adjusts along what he has done.
>>
>> Also Adam and I need to work out App B and drip-auth.
>>
>> So there may be yet an update before the cutoff.  Of course comments are
>> welcome and I will make adjusts as needed.
>>
>>
>>
>> On 10/20/21 4:13 PM, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>> This draft is a work item of the Drone Remote ID Protocol WG of the
>> IETF.
>>>           Title           : DRIP Entity Tag (DET) for Unmanned Aircraft
>> System Remote Identification (UAS RID)
>>>           Authors         : Robert Moskowitz
>>>                             Stuart W. Card
>>>                             Adam Wiethuechter
>>>                             Andrei Gurtov
>>> 	Filename        : draft-ietf-drip-rid-11.txt
>>> 	Pages           : 29
>>> 	Date            : 2021-10-20
>>>
>>> Abstract:
>>>      This document describes the use of Hierarchical Host Identity Tags
>>>      (HHITs) as self-asserting IPv6 addresses and thereby a trustable
>>>      identifier for use as the Unmanned Aircraft System Remote
>>>      Identification and tracking (UAS RID).  Within the context of RID,
>>>      HHITs will be called DRIP Entity Tags (DET).  HHITs self-attest to
>>>      the included explicit hierarchy that provides Registrar discovery
>> for
>>>      3rd-party identifier attestation.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-drip-rid/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-drip-rid-11.html
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-rid-11
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>> --
>> Tm-rid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tm-rid
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>