[secdir] Secdir review of draft-ietf-drip-rid-07

Magnus Nyström <magnusn@gmail.com> Sat, 24 July 2021 05:14 UTC

Return-Path: <magnusn@gmail.com>
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 1B6173A2B52; Fri, 23 Jul 2021 22:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P6CZyxOXk8f; Fri, 23 Jul 2021 22:14:42 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46CB3A2B50; Fri, 23 Jul 2021 22:14:41 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id l126so4977767ioa.12; Fri, 23 Jul 2021 22:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NQ4MjXiR8wjrB/fs+Cfbfj0NJJv0yy1ZsFY6T+ISKEw=; b=KdEwCsUkUqF/DszP8WLgqsR8qPbb9aBw9VuA4GJg8jeBl2oz2W+PtfgGfF8dsokrPp ixsbTOPK8B3ZfMOovfda030vNmKOT3kUEbbF5Nvs2sG2LKX1YBmGJpyYqlVdSoE8ygsT N4DxQxGRkreL1yJ+LK9gjtjmWNiD88zcgeQj+sCGco/TLwL6mYYZLwwx5JA/1AUMhDk3 KJSMWGUYBNQL1Y+GAyXVdGQ9Wnz0VPpvutrErhWfTpFbGfKxZRNJ2ZiW4hMEGXtK1beO hkDTHsWOk1ji5hmelG3fKBlGh13j/yONB55NHhlye8sICjE1PeaeZ7qXJAjd/8lfGoAh k0Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NQ4MjXiR8wjrB/fs+Cfbfj0NJJv0yy1ZsFY6T+ISKEw=; b=VA+oebReTZViJMxY8ZnO0fft8jq8xlBcL0WfbWT7618QjAfJJ+3l6EIW2YFn4CCIAT 3+ulZOYelzJDANIY1GgwFEeO7I3L6xRFDvOnKpUR5whgjx5eOVYEKRiXid+J0tMuxPhe bkPMrA6oBy0YLv4qNgMexMjkNEzlletuzVQbOZAt4JP1rG5aWHVwdMR4STY5Zv3XREHf 5A2oQpqG889QNfXl9E9VSsmJ65XDwrBLlbHpozEyfqfo4KF0P4rk3BRUbgtgtbhAdIsd 5M3tyjazWiaA+Miv68udOb3i9ZkKdQsIhsC77dYaWwseUb/lI6yVaKGbEIKJE681rL2C h40Q==
X-Gm-Message-State: AOAM530q0FG8it9zW9S3/G8GG8ExI4gpa01+dEBbhAIYpIz5V6A9a1S2 mlDzXpNDQQZ6soU1qzviQglL1MlYiQubP54o/974z/hnefE=
X-Google-Smtp-Source: ABdhPJzMujNL4DptV+mdN6ZD1PjcIWExy5qIdBMD346set3p23QzxpDmWxtu6TV8LQH8O3z5kH5yOhuYY01P1uzf3VI=
X-Received: by 2002:a02:cebb:: with SMTP id z27mr7084415jaq.72.1627103679940; Fri, 23 Jul 2021 22:14:39 -0700 (PDT)
MIME-Version: 1.0
References: <CADajj4ZQnWkjKdWpBgsB0oyX8_Kzj6HOL-Vkm=TrByBQMEJfPw@mail.gmail.com> <CADajj4bCTF5EeF6DZkCHpP0_GTnUYQtqa0OE3qf3Z5_AmKWfyA@mail.gmail.com> <CADajj4YxgdNXkWX7dLP0nBDWXLSKFa8M_KWWCPCgfCibYtWkAw@mail.gmail.com> <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com> <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com> <CADajj4aoBaSYTFFnvAjcL7mTnfoUJOWzvve=NRhgB3qe5X8uWQ@mail.gmail.com> <CADajj4ZTBoCHo2=RJhYFNMi+5L5JJwc_EqBkeyYUUfYsVk-vVw@mail.gmail.com>
In-Reply-To: <CADajj4ZTBoCHo2=RJhYFNMi+5L5JJwc_EqBkeyYUUfYsVk-vVw@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Fri, 23 Jul 2021 22:14:29 -0700
Message-ID: <CADajj4bAjmbXjQkzJPXBihWZko2msmrHG=-4D9zF4YaFAeU0XA@mail.gmail.com>
To: secdir@ietf.org, draft-ietf-drip-rid@ietf.org
Content-Type: multipart/alternative; boundary="000000000000db0a6105c7d79822"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/s9i3aqqqzwAmhFSn0hRBKsxqlGw>
Subject: [secdir] Secdir review of draft-ietf-drip-rid-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 24 Jul 2021 05:14:48 -0000

 I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other comments.

This document describes the use of "Hierarchical Host Identity Tags" as
self-asserting IPv6 addresses and thereby trustable identifiers for use as
Remote IDs.

As the security of HHITs to a large degree relies on the security of the
cryptographic constructs and primitives described in this document, I would
recommend that the IRTF CFRG or a similar group with cryptographic
expertise reviews this memo (unless it has already been done).

The security of the HHITs also seem to depend to a large degree on the
registrars (registry operators) that will act as backstops to ensure no
duplicate registrations etc. It might be helpful with a clear statement as
to the conditions that must be met by registrars in order for this scheme
to be secure.

As noted, the use of a 64-bit hash is weak when considering pre-image
attacks. I do not understand the constraints the authors have been working
under in this context enough to say if there was an option for a longer
hash, but I think this should be part of the above suggested CFRG review.

The text "Another mitigation of HHIT hijacking is if the HI owner (UA)
supplies an object containing the HHIT and signed by the HI private key of
the HDA such as Appendix E.1
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#appendix-E.1> as
shown in Section 3.5"
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.5>
confuses me a bit since I don't see how the subject of an attack would be
able to tell should the HHIT hijack attempt occur before the HI owner has
supplied such an object?

Lastly, the statement "The authors believe that the probability of such an
attack is low when Registry operators are using best practices" seems weak
and would preferably be backed with some more quantitative analysis or at
least specific statements around best practices and how they would reduce
the probability.

Editorial: The document is in need of a grammar / wording polish but I
expect the rfc-editors to handle this.

Thanks,
-- Magnus