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

Valery Smyslov <valery@smyslov.net> Thu, 12 May 2022 14:53 UTC

Return-Path: <valery@smyslov.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408CFC1594B5; Thu, 12 May 2022 07:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEDv8XinggnG; Thu, 12 May 2022 07:53:36 -0700 (PDT)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF97C157B55; Thu, 12 May 2022 07:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ifeTeciK2Z88sZWONYGBrAVvweLUiCbnQADOcTABWGw=; b=nCsudmY9rq1G5Pc84z89nRQkkC 7YPMvdqmzNbb5rQo8qsSAsX8e8S4lvMWazypco2Bf+axp8Zkxwr/iRPlZq3CCyxCJMe5BvaQaFldN YFTI4oS36pucyaD8hMX375x0uBpNduv5oRxpl0nYGiRmEQ92nn3Ib/6/gkPPEe8n7ZNJbUUHiBSZd 9UTIfU/LRoUdwMsi5AruX3Von4tXllHQX4Qv7eoGnjyHNkAaKhcvKyjI6KEVxcehqh/h/bCLojyts qYSq3+nUKOpmRh0DkeR5JK4v7cgvo+OulQTMbfgAUlwYZzjZnqnzRBIE1dg1Z5SH84ax7iXLeG2yV yN4sYKeQ==;
Received: from [93.188.44.204] (port=53733 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <valery@smyslov.net>) id 1npAC0-0004P4-Q5; Thu, 12 May 2022 10:53:29 -0400
From: Valery Smyslov <valery@smyslov.net>
To: 'Robert Moskowitz' <rgm@labs.htt-consult.com>, 'shuai zhao' <shuai.zhao@ieee.org>, "'Stuart W. Card'" <stu.card@axenterprize.com>, 'Robert Moskowitz' <rgm@htt-consult.com>
Cc: draft-ietf-drip-arch.all@ietf.org, last-call@ietf.org, tm-rid@ietf.org, secdir@ietf.org
References: <164864828914.19999.4038160950945043224@ietfa.amsl.com> <PH0PR17MB5728869B4521B619367A133AF4CB9@PH0PR17MB5728.namprd17.prod.outlook.com> <316c01d86605$738d9d80$5aa8d880$@smyslov.net> <03e602ed-c970-dccd-2e7c-99a976978a8c@labs.htt-consult.com>
In-Reply-To: <03e602ed-c970-dccd-2e7c-99a976978a8c@labs.htt-consult.com>
Date: Thu, 12 May 2022 17:53:28 +0300
Message-ID: <318601d86610$0c9f8380$25de8a80$@smyslov.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_3187_01D86629.31EEB750"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHAkWuyxQUkzf87mu+hlPYoCbOlNwHqI8oqAjJIW7oBeWCnm60eTmZg
Content-Language: ru
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/BMK4BuVWfECtHu34qikE9XmKTK0>
Subject: Re: [secdir] [Drip] Secdir last call review of draft-ietf-drip-arch-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2022 14:53:40 -0000

Hi Bob,

 

From: Robert Moskowitz [mailto:rgm@labs.htt-consult.com] 
Sent: Thursday, May 12, 2022 5:30 PM
To: Valery Smyslov; 'shuai zhao'; 'Stuart W. Card'; 'Robert Moskowitz'
Cc: draft-ietf-drip-arch.all@ietf.org; last-call@ietf.org; tm-rid@ietf.org; secdir@ietf.org
Subject: Re: [Drip] Secdir last call review of draft-ietf-drip-arch-22

 

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

 

Hi Valery, 

 

We have this  <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/40> 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  <mailto:noreply@ietf.org> <noreply@ietf.org>
Date: Wednesday, March 30, 2022 at 6:51 AM
To: secdir@ietf.org  <mailto:secdir@ietf.org> <secdir@ietf.org>
Cc: draft-ietf-drip-arch.all@ietf.org  <mailto:draft-ietf-drip-arch.all@ietf.org> <draft-ietf-drip-arch.all@ietf.org>, last-call@ietf.org  <mailto:last-call@ietf.org> <last-call@ietf.org>, tm-rid@ietf.org  <mailto:tm-rid@ietf.org> <tm-rid@ietf.org>
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.

?

          Fine, thank you!

          All my concerns are addressed.

          Regards,
          Valery.


Bob