Re: [secdir] [Drip] Secdir last call review of draft-ietf-drip-arch-22

[Robert Moskowitz <[e-mail]>]

I have cut the reply to include only the one action item:

On 5/12/22 09:37, Valery Smyslov wrote:
>
> Hi Shuai,
>
> *From:*shuai zhao [mailto:[e-mail]]
> *Sent:* Thursday, May 12, 2022 3:11 AM
> *To:* Valery Smyslov; Stuart W. Card; Robert Moskowitz
> *Cc:* [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> *Subject:* Re: Secdir last call review of draft-ietf-drip-arch-22
>
> Hi Valery,
>
> We have this Github issue tracker 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/40> for 
> your comments. Please see our response below.
>
> thanks for the github reference. Please see my comments inline.
>
> *From: *Valery Smyslov via Datatracker <[e-mail]>
> *Date: *Wednesday, March 30, 2022 at 6:51 AM
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Secdir last call review of draft-ietf-drip-arch-22
>
> Reviewer: Valery Smyslov
> Review result: Has Issues
>
> The topic of the draft is complex and involves many fields which I'm 
> not expert
> of. The overall architecture looks secure, however it's difficult for 
> me to
> analyse all the details. Nevertheless, it seems to me that there are some
> security issues with the draft.
>
> 3. Section 9.
>
>    The size of the public key hash in the HHIT is also of concern.  It
>    is well within current server array technology to compute another key
>    pair that hashes to the same HHIT.
>
> If I understand the draft correctly, the size of public key hash is 20 
> or 19
> octets (Section 3.1).
>
> Bob/ The architecture document does not detail the format of an HHIT.
>
> It turns out that in draft-ietf-drip-rid, the hash size is 64 bits so 
> this attack is real and details about it are in the Security 
> Considerations
>
> of that draft. Perhaps say:
>
> The size of the public key hash in the HHIT (64 bits) is also of concern
>
> Finding another key pair that hashes to the same hash
> requires second preimage attack, which must take in this case 2^160 or 
> 2^152.
> In my understanding of the state-of-art, it's still beyond 
> possibilities of
> current computers. Am I missing something?
>
> Bob/ Unfortunately you have to see: draft-ietf-drip-rid-17 sec 10.
>
> [Med] The initial point was to record the potential security 
> consideration that should be further examined in the solution spec.
>
> I'm not convinced we need to call out solution-specific details (e.g., 
> 64 bits) here or call out ietf-drip-rid.
>
> I still think that the current text is confusing: it states
>           that the size of public key hash in the HHIT allows
>           to find second preimage without any hint on what the size is 
> or can be.
>
> I think that a way to eliminate this confusion without mentioning a 
> concrete value would be to modify the text
>           that **if** the size of public key hash in the HHIT is 
> chosen not large enough by solution spec,
>           then it may be possible to find second preimage and so on.
>

Valery,

    The size of the public key hash in the HHIT is also of concern. If 
the size
    of the public key hash in the HHIT is not large enough, it could be 
within current server
    array technology to compute another key pair that hashes to the same 
HHIT.

?

Bob