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

[Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx>]

    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:shuai.zhao@xxxxxxxx]
Sent: Thursday, May 12, 2022 3:11 AM
To: Valery Smyslov; Stuart W. Card; Robert Moskowitz
Cc: draft-ietf-drip-arch.all@xxxxxxxx; last-call@xxxxxxxx; tm-rid@xxxxxxxx; secdir@xxxxxxxx
Subject: Re: Secdir last call review of draft-ietf-drip-arch-22

 

Hi Valery,

 

We have this Github issue tracker for your comments. Please see our response below.  

 

          thanks for the github reference. Please see my comments inline.

 

From: Valery Smyslov via Datatracker <noreply@xxxxxxxx>
Date: Wednesday, March 30, 2022 at 6:51 AM
To: secdir@xxxxxxxx <secdir@xxxxxxxx>
Cc: draft-ietf-drip-arch.all@xxxxxxxx <draft-ietf-drip-arch.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, tm-rid@xxxxxxxx <tm-rid@xxxxxxxx>
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
    
    
  

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call