[secdir] Secdir review of draft-ietf-sidr-rpsl-sig-10

Magnus Nyström <magnusn@gmail.com> Mon, 09 May 2016 06:55 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 ECC6812B024; Sun, 8 May 2016 23:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 vkJJpOJudyfA; Sun, 8 May 2016 23:55:31 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 C4C4312B04E; Sun, 8 May 2016 23:55:31 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id x201so200405367oif.3; Sun, 08 May 2016 23:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=KyM45i+Eb2FSm5XtRJuZWpGXRyY0Lr465kpByBAvI2w=; b=CadWH41nxrj712chemp1NSZYxpSRTe0wsGEKbKzj1iMmzq9D2YgZdI4TZWgOhIQLB1 qPX2s8Qdo1iOmpD8LXebRsLUG8rw9squYYB6OaClr4B1aRw0BmoBog3WYlJVQTbx8szX RMF28kcq0xOIs+A8sD7Ho2078JJdC19n7yk6KqywZESSAD1FUyVIknOugPrY2u5GaaKk y+WS0vgMnhSFlMYkJayEulW9LVHVJN6Fy9O89ZBnQe438tpXQt5madf2Z+b9O58+n7wW +U8ACWaPk1D2AAW+al6w+7K5SKp7mZX2pD8EcnI2BcpK4RAgPiqOunWkua6K9oMYhYX0 v65Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=KyM45i+Eb2FSm5XtRJuZWpGXRyY0Lr465kpByBAvI2w=; b=gHrEn+X3YEtXWOurTtLy6P4JCzLimne4cv2anwj7+JIAeElo2oog3TFpg/vh9CA6D2 v2yzbGXSS8AxBnZJD547E8ENE4O/hXyu9aKbvBvPtIUUmdwyl7QHE0Pylw8XDja8PVQH 3GDhvlaAfWkrGkX25sTujqaPco2wSpRI+L6212w7oPwumb7GNGl+KGdBCIx5kI9pAlOV AUN9+iNf8+PgE2O1Cx2q2qfNvyCN7p6sNLNOES6H9by9cq5OluYSKtXy7EF9ueONDjeB 1QV6oe2gEdLdagd1Coa4Q2RBF08Wwg2U0nu8+WhhpZz0ILNC7SB1cRYkCHhDslY36/DT 4DYQ==
X-Gm-Message-State: AOPr4FUCLlXoVyirZDlBjTmH9H4TKO6QRvO3jmGybPTX5Sq+gnvnRXVb6o8envDHC8DexbkZAGkkgJ8k870w1g==
MIME-Version: 1.0
X-Received: by 10.157.18.143 with SMTP id g15mr13813097otg.125.1462776931121; Sun, 08 May 2016 23:55:31 -0700 (PDT)
Received: by 10.202.108.137 with HTTP; Sun, 8 May 2016 23:55:31 -0700 (PDT)
Date: Sun, 8 May 2016 23:55:31 -0700
Message-ID: <CADajj4a8OdAfHhev_u4u7UftqrSjiw0JttNgM=6=OsCDmtq0Dw@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-sidr-rpsl-sig.all@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c03cec45d806e0532634b22
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ye7RL6491HP9MUwgvx7kGjQaHsU>
Subject: [secdir] Secdir review of draft-ietf-sidr-rpsl-sig-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 09 May 2016 06:55:34 -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 last call comments.

This document describes a mechanism for digitally signing Routing Policy
Specification Language (RPSL) objects. The digital signatures are intended
to ensure authenticity and integrity protection of such objects when they
are transferred to and from resource databases.

- The signature scheme is a little unusual in that the signature attribute
lists the names of the attributes that are part of the signature rather
than just including those attributes (and their values) as part of the
signature attribute itself; I assume this is due to a need to preserve
established RPSL object syntax but it doesn't seem required for this
application which essentially is a transport format. The cost here is, of
course, the need to duplicate the names of the signed attributes in the
signed RPSL object (once for the regular attribute value and once for the
value in the signature attribute).
- There is an expectation that relying parties fetch the signer's
certificate based on a URL in the signature attribute. This may be a
dangerous practice, since the URL needs to be contacted before the
signature can be validated. A malicious party may insert a URL that will
lead to an attack. I suggest this be noted in the Security Considerations
section with some suggested best practice, e.g., only https and careful
parsing of the retrieved resource.
- The Signature Method field - how are new algorithms identified? Is there
no need for protocol action / IANA action to register new algorithm for use
with this memo?
-- As for the canonicalization, this is an inherently complicated field. It
does not, for example, seem as if the memo describes how to canonicalize
multi-valued attributes. The ordering of such values may well be
implementation-dependent post object parsing and thus, the canonicalization
should cover how to order sets or sequences of values.
- The last paragraph of the Security Considerations brings up an important
point but provides no guidance to an implementer how to handle this case /
detect the situation. Preferably some advice should be given here.

Editorial / questions:

Section 1:
- "This means when downloading a Routing Policy Specification Language
(RPSL) object stored in this database, one can reasonably safely claim that
the object is authentic, but for an imported object one cannot." Two
points: First part of sentence likely misses a "that." Secondly, what's
referred to with "this" database?
- "A maintainer of such signed database objects MUST possess a relevant
resource certificate, which shows him/her as the legitimate holder of an
Internet number resource." Why does a maintainer of objects need to possess
a resource certificate? I think the party generating signed database
objects need such a certificate, but not necessarily all maintainers?

Section 2:
- "When verifying the signature of an object, the verifier has to check
whether the signature itself is valid, and whether all the specified
attributes are referenced in the signature." What "specified" attributes?
- It would be very helpful with a full example, not just an outline as in
2.3.
- Section 2.4 talks about multiple signatures. I believe this is the only
place where this is done, and it is also confusing given that earlier text
stated that each attribute (and the signature is an attribute too), must be
present "at most once"?

Section 5:
- The certificate shouldn't be used for more than one verification - was
the intent to say that the private key associated with the public key
present in the certificate shouldn't be used to sign more than one RPSL
object? It seems difficult to state that a certificate can be used for
verification only once - multiple relying parties may verify it, for
example (note: I am not too familiar with RFC 6487 so may be missing
something here).

-- Magnus