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: Magnus Nyström <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
- [secdir] Secdir review of draft-ietf-sidr-rpsl-si… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-sidr-rps… Brian Haberman
- Re: [secdir] Secdir review of draft-ietf-sidr-rps… Magnus Nyström