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

Magnus Nyström <magnusn@gmail.com> Fri, 13 May 2016 15:47 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 9C50512D581; Fri, 13 May 2016 08:47:57 -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 xf1MiiXXhauK; Fri, 13 May 2016 08:47:55 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 6F3A012B060; Fri, 13 May 2016 08:47:53 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id v145so176457720oie.0; Fri, 13 May 2016 08:47:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sSB5U8l3SBzwIN+O+phYveqTcnTYGbVJyZofpHUEBEw=; b=FbquK8oQswM7qKXywNfVRqMpcDCq8PXX0NBfwFCe7AlzCofLoJIkXNUtRIwETWYg0v 4UUiLIrbIhhMNhMTlgomAp8/Z7i0ON6pIKFurQvX75pCUq6ge7X4b0i+525ng1u7MFCI sHk9BFzFcXEcHZUQhmhhPYfSv7xGUFM6zRaFIHOSMfGr3+Kpk6DBsbn/YL1ObeYespQp mbmGVV9vHw/MinqMFecoT+reMIdIV9mNdFnd4Q3G3XzC3BUxikT4njISj/82qHYJJ22S qCP/U8JV+Pbllkpzlm6o8M//uZ3sn2Innvy8ndRURBwUSIh1ljzPeu74DgJ0SvacXMPe kd2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sSB5U8l3SBzwIN+O+phYveqTcnTYGbVJyZofpHUEBEw=; b=Hrx34BGmsucdnTQr9nbXKtLIX8uDijveUb56Vhx0z3T1ghQhtjC2ZfsS/91OufmVSN c+EEzy1nE13ZUZJsUwqLzPNHKPmVAVG/dpQw4Ko+9ymnuVunF9YdQncBTQ7n6Gy1uVDc e7AX6LQEaFKTVcsFFxtvPDnO3DKJ56Ad2H6MP0VmcglvMgF6IvHTRx64CCFA9L8GonZF SWiYGtvrdGLa6I2SEkhc3ISraQO0Lb24S8pv+vt1EBAFxuWS/22PXAAkyzEYaWIxet0B 5bX7P05zN/bvhaNwlA5bGDmLRfRE+vu/UsRsxPeudBbxx0WvntJ/Qmx17mAfh4WYK0El sMLQ==
X-Gm-Message-State: AOPr4FVqNE5eKK23oOp5+PYiFcxH0e47iSDngQtSmNQhhgDunzv+GlW7z8+xitM63oqvZ04xC53T71ednW5gug==
MIME-Version: 1.0
X-Received: by 10.202.240.215 with SMTP id o206mr8301301oih.132.1463154472783; Fri, 13 May 2016 08:47:52 -0700 (PDT)
Received: by 10.202.108.137 with HTTP; Fri, 13 May 2016 08:47:52 -0700 (PDT)
In-Reply-To: <573334A9.2050300@innovationslab.net>
References: <CADajj4a8OdAfHhev_u4u7UftqrSjiw0JttNgM=6=OsCDmtq0Dw@mail.gmail.com> <573334A9.2050300@innovationslab.net>
Date: Fri, 13 May 2016 08:47:52 -0700
Message-ID: <CADajj4Y4W3-hFx2QzvwUwiP0s3NBggCj2H2NqtTydBsiZ8aB-g@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Content-Type: multipart/alternative; boundary=94eb2c09204e9a197b0532bb32d9
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/YeNNhHGsE0FDjXWbXA5cklBMYvw>
Cc: draft-ietf-sidr-rpsl-sig.all@ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Fri, 13 May 2016 15:47:57 -0000

Thanks Brian,

On Wed, May 11, 2016 at 6:33 AM, Brian Haberman <brian@innovationslab.net>
wrote:

> Hi Magnus,
>     Thanks for the review and comments. Responses are in-line...
>
> On 5/9/16 2:55 AM, Magnus Nyström wrote:
> > 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).
>
> As noted in Section 2, this approach is similar to the one taken by
> DKIM. It is designed to allow backwards compatibility with systems that
> have not been upgraded to recognize the new 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.
>
> It is unclear to the authors what "careful parsing" means here and
> HTTPS-only in the context of RPKI-hosted certificates creates other
> complications that may exceed the benefits.
>

Well, it seems to me that the ability to get agents to contact an
unverified URL is a potential risk and I would recommend some discussion
around this in the Sec Cons section..

>
> I would suggest that we add a pointer to Section 7 of RFC 6487 to the
> Security Considerations section of this draft. That portion of 6487
> describes the certificate validation methodology for these certificates.
>
> > - 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?
>
> We don't think so. This approach follows the approach of RFC 4055.
>
> > -- 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.
>
> In my experience, RPSL servers do not modify the order of sets or
> sequences when importing/exporting objects. The necessary
> canonicalization text for such objects is mentioned in point #5 of
> section 3.1.
>
> If you think it would help, we could add something along the lines of
> "The ordering of multi-valued attributes in c14n must preserve the
> original ordering in the object" to point #5 in 3.1.
>
> I would suggest this, since in general canonicalization should allow to
first parse a received message and then later do verification with a
successful result without relying on implicit expectations on behavior.

> - 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.
>
> An entity is free to sign whatever attributes it wants. So, it is up to
> the consumer to decide what attributes he/she cares about. Given that we
> can add a sentence to the Security Considerations section saying that
> consumers of signed RPSL objects may validate signed resource attributes
> if methods exist to do so.
>
> Yes, that may be helpful.


> >
> > 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?
>
> Would the following be more clear?
>
> OLD:
>
> 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.
>
> NEW:
>
> This means that when a Routing Policy Specification Language (RPSL)
> object is downloaded from a database, the consumer can reasonably claim
> that the object is authentic if it was locally created, but cannot make
> the same claim for an object imported from a different database.
>

Much better, thanks.

>
> > - "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?
>
> Agreed that "a maintainer" can be changed to "the creator".
>
> >
> > 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?
>
> The list of signed attributes is identified by the "a" field in the
> signature. The attributes listed in "a" need to be in the object.
>

I would suggest "all the attributes specified in the "a' field".

>
> > - It would be very helpful with a full example, not just an outline as in
> > 2.3.
>
> I will try and generate one.
>
> > - 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"?
>
> This will be applicable when text removed in an earlier version is
> restored that allows for multiple signatures.
>

Is that intended to be restored before publication? If not, suggest
removing.

>
> >
> > 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).
>
> Correct. This should be signature generation.
>
> Thanks for the feedback.
>
> Thanks


> Regards,
> Brian
>
>
>


-- 
-- Magnus