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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
