Re: [Last-Call] [Drip] Intdir last call review of draft-ietf-drip-rid-26

[Robert Moskowitz <[e-mail]>]

I had pushed out -27 with the changes I made from our first go-around.  
Look for a -28 with changes from this set of responses.

On 5/17/22 04:27, Pascal Thubert (pthubert) wrote:
> Hello Robert
>
> Most of my comments are indications that the reader might wonder what I wondered, and some little editorials at the places I ticked could improve the readability and the smooth transit through IESG. In particular, having an appendix or what that discusses the address as an ID and fwd pointing it in the intro, would save predictable hassle in the next steps IMHO.

And I do appreciate the "outside the echo chamber' review!

>
>
>>>>     HHITs are statistically unique through the cryptographic hash feature
>>>>    of second-preimage resistance.
>>> Good thing that the HHITs are Hierarchical as opposed to only Statistical ;)
>> The original design for HITs allowed for a 1-level 'hierarchy'.  My
>> co-authors at that time did not see a use for it and we removed it, but
>> go back to draft-moskowitz-hip-arch-02 and later
>> draft-zhang-hip-hierarchical-parameter.  Now there is a use case and I
>> believe the design is good.
> Since that was you and your keen eyes, I took the liberty to add some amount of second degree. Sorry I should have hinted.
> In this case, my poor sense of humor - though the first degree was very true too.

And I took it in the implied humor.

>
>>>> 2.  Terms and Definitions
>>> A forward ref to fig 1 would help with all the bit fields.
>> Please check out changes to HDA, HID, and RAA.  How is this change? Do
>> you want this on any other defs?
> Happy to but where? Is there a github?

Sorry.  I pushed out -27 with this change.  I don't do github.  I have 
not figured out github.  Since draft versions are free, I freely update 
them with each round of updates.  Also I do all my draft writing in xml 
and locally use xml2rfc and then view the resultant txt.  I also use 
rfcdiff before I submit a new ver just to check on the changes I made 
from the prior ver and that I am 'happy' with the actual changes.

So for this round of changes, check out -28 and you can run the diff 
between -26 and it to get all the changes I made for your comments.

>
>>> Could issues arise when the global registry is unreachable when the ID is
>>> formed? Is the HHIT "tentative" till then?
>> Really can't use it until it is registered.  HHIT owner has no assurance
>> that it is unique.  And if the RAA will accept the registration for
>> whatever reason.
> Actually this was an indication that the reader may be wondering and may love to see text enriched, with e.g., the above.

See the expanded text in sec 1.1 in -28.  Let me know if this clarifies.

>
>> Do you think you can get IESG to 'vote' that DETs get a /24 or even a
>> /20 prefix?  ;)
> If your encoding is future proof enough... /24 looks like a good start, that 6MAN would love to see for the /64 alignment thingy; maybe ask for a /20 where you use only a /24?

What would be the process to get acceptance for a smaller prefix.  A /24 
would work for DETs.  A /20 COULD allow for multiple uses for HHITs.

I am still bruised from asking for the /28 with HIPv1!  Perhaps now 
there is a better understanding of the non-routable space usage and a 
smaller prefix would not create a strong pushback?   I had heard of 
other non-routable uses only able to get /32 and so I was working on not 
asking for more than previously issued.

>
>>>> 4.1.  Nontransferablity of DETs
>>>>     A HI and its HHIT SHOULD NOT be transferable between UA or even
>>>>     between replacement electronics
>>> Pro: This answers one question above.
>>> Con: this bars very interesting IoT use cases I have in mind for spare
>> parts
>>> and sensory devices. e.g., ISA100.11a uses IPv6 addresses as IDs and would
>>> benefit from this.
>> This is for HHITs as DETs.  HHITs (with a different prefix) for other
>> stuff could have other behaviors.  I would love to pursue this with you.
> Could we then word the above as " A HI and its DET SHOULD NOT be transferable between UA ..."?
> The title is already fine but the text inside could be misinterpreted.

Done.

>
>> This mirrors 7401 HIP registry which predates 8928.
>>
>> I question the value, here in this registry, to go back to where each of
>> these are defined.  Other than the referenced rfcs?
> Reference RFCs is fine, that's what RFC8928 does when available.
> My point is that creating yet another registry is overhead. Happy that you extend the HIP one.

It could strongly be argued that this new registry should be called the 
HHIT Registry.  So that it is better open to uses of HHITs beyond DETs.  
Further some might argue that these are really sub-registries under the 
HIP registry.  As HITs are a creation of HIP.

All this are meta debates that could be discussed at a higher 
organizational level.  I am open to either placement.

> In parallel, is there a way to fix the issues you have with RFC 8928?

8928 is addressing a different set of issues with a different internal 
debate.  My concern, with all the options is what will be 
implemented/fielded and how will interop work?  It is not like 
TLS/IKE/HIP where these is a algorithm negotiation process? Personally, 
I just did not have the mental strength to engage in yet another 
activity.  :(

>>> is not post-Q resilient right?
>> No 2^64.  That was a error up there in Fig 1.  Thanks for catching that.
>>
>> Not PQ resilient.  No viable PQC solution at this point that we can
>> shoehorn into this small size dictated by other regulations.  One one
>> hits the surf, we can allocate a HHSI for it.
> Another instance of me suggesting to add a few words in the document like the ones above ;)

I just caught where I say 60-bit hash in this section.  Oops.  That 
whole clause is a hold-over from the old 4/8 bit OGA construct.  I have 
removed it.

I took sec 8.1 on PQC from drip-arch, altered it slightly and put it 
here as well.  So I restate matters for clarity on this point.

>>>> 9.4.  Collision Risks with DETs
>>>>     The 64-bit hash size does have an increased risk of collisions over
>>>>     the 96-bit hash size used for the other HIT Suites.
>>> Is that true also for voluntary collisions (brute force) ?
>> ?  that is what this section is about.  Straight probability stuff. What
>> can be brute forced?
> Someone wanting to create a key pair that would generate the same ID to steal the ID and impersonate. Is that an issue here?

I added some text at the end of this section for clarity.

Watch for -28 posted soon!

> Otherwise all good!
>
> Pascal

Bob