Incorrect HOST_ID input to cSHAKE128

[kc2rxo]

Looking at RFC9374, the hash input is defined as follows:

cSHAKE128(Input, L, "", Context ID)

Input      :=  Prefix | Additional Information | OGA ID | HOST_ID
L          :=  Length in bits of the hash portion of ORCHID

The combination of Prefix | Additional Information | OGA ID are implemented as the variable h_orchid_left in det_orchid().

HOST_ID is, per RFC9374, defined as:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         EdDSA Curve           |             NULL              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Public Key                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In det_orchid() the call

drip-scripts/det-gen.py

Line 51 in 77f7ba5

shake.update((h_orchid_left + hi))

with hi = prkey.public_key().export_key(format="raw") does not match the Input for cSHAKE128 as the HOST_ID is missing both the 2-byte EdDSA Curve enumeration and 2-bytes of null padding before the public key (hi).

The correct call is: shake.update((h_orchid_left + bytes([0, 1, 0, 0]) + hi)) -- assuming the EdDSA Curve in use for this script is always Ed25519, enumerated as the value of 1.

@rgmhtt please confirm.

[tuupola]

I also read the RFC again and this is how I understand it too. The EdDSA curve is missing. Good catch.

[kc2rxo]

I have poured over RFC4701 and RFC9374 and think to have found something ambiguous.

In RFC7401 is seems to me that the what is included as part of the hash input is the field Host Identity from the HOST_ID parameter. When using ECDSA this would include a 2-byte field denoting the curve in use. This aligns from what I see in existing implementations of HIPv2 such as OpenHIP. As a note RFC7401 is hard to read as the text that states the above fact is in Section 3 but is never repeated anywhere. What would of helped is that somewhere the ORCHID process figure should of been used to clearly indicate the inputs for each Suite ID - but I digress.

In RFC9374, the hash input indicates a field called HOST_ID which is ambiguous to me in its context. Is that the entire packet format of the HOST_ID parameter of RFC7401 defined in Section 5.2.9? Is a typo in RFC9374 and should be clarified to be "the Host Identity field from the HOST_ID parameter of Section 5.2.9 of RFC7401"? Text of RFC9374 suggests the later interpretation.

@cardsw brought up the point in discussion today that under DRIP and other broadcast regimes that are not bidirectional, we need to be aware of what is being used as a hash input. He is worried that a receiver may not have all the information needed to perform the hash validation. We also need to be aware that at this moment curve selection (in either ECDSA or EdDSA) can be trivially identified by the length of the key presented to you - this is not guaranteed unless its a consideration when adding a new curve selection to either the ECDSA or EdDSA IANA registries.

[tuupola]

Any news about this?

As a sidenote I think any algorithm agility based on keylength is a footgun in the future.

[kc2rxo]

I had a chat with @rgmhtt today over the phone on this (@cardsw sitting in later). He is digging back through to ensure we do not tread onto ground that was deemed unsafe for some cryptographic reason.

The intent from his memory was for it to include the "EdDSA Curve Label" as part of the hash input (i.e. "use the Host Identity field from the HOST_ID parameter"). This also aligns with the existing process for ECDSA in RFC7401. Thus, me and Bob and working towards a few erratum to file on RFC9374 and RFC7401 to clarify some things.

Rant: I call into question why there is a whole new "EdDSA Curve Label" table when it could of maybe just been part of the existing "ECC Curve Table" (lots of libraries I see group EdDSA with other existing ECC functions/classes) but I am sure there was good reason for this from a protocol standards perspective.

The above intent aligns with the changes made in the linked PR and thus can be merged once Bob confirms fully no outstanding issue, we foresee none of significance to impede such a change.

@tuupola in direct response to your sidenote:

We have one outstanding "gotcha" that affects DRIP-only users (HIP-only users are fine). The EdDSA Suite ID (5) is, from our discussion at this current time, implicitly selecting the Ed25519 curve. Everything in DRIP is built around this curve thus distinguishing between them (Ed25519 and Ed448) is an open "gotcha". In HIP this difference is covered by the HOST_ID parameter of RFC7401 and the existing HIP RRType format for DNS retrieval.

For DRIP, the use of X.509 for the HHIT RRType certificate avoids the issue as it includes in the SubjectPublicKeyInfo the curve. It also is avoided as RFC9575 is scoped only to use Ed25519. One MAY get away with do a mix of an Ed448 entity endorsing an Ed25519 entity, but we don't see this as being a common thing plus it would require a revision of RFC9575 to support.

We MAY update the Suite ID table to have independent enumerations for each curve+hash. Unsure at this time as this should be done for ECDSA (P-256, P-384 curves) at minimum as well.

It is an open question on future key algorithms, however it was discussed between the two of us that in the future (specifically in regards to PQC) we will burn through a series of Suite IDs to indicate not just algorithm family or key size but also any other fixed parameter sets. Hence, the MAY update the Suite ID table comment above. We do agree with you that a Suite ID MUST NOT have the user rely on the length of a key to determine which "subset" of key it is (such as its curve).