Re: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

Brian Haberman <brian@innovationslab.net> Wed, 11 May 2016 16:57 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD6012D142; Wed, 11 May 2016 09:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 jGf8Tc94mxUf; Wed, 11 May 2016 09:56:59 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608F812D11C; Wed, 11 May 2016 09:56:59 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 52BFD880F5; Wed, 11 May 2016 09:56:59 -0700 (PDT)
Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 009F7328081A; Wed, 11 May 2016 09:56:58 -0700 (PDT)
To: Randy Bush <randy@psg.com>
References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> <m2shxoeeby.wl%randy@psg.com>
From: Brian Haberman <brian@innovationslab.net>
Message-ID: <57336455.1040508@innovationslab.net>
Date: Wed, 11 May 2016 12:56:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <m2shxoeeby.wl%randy@psg.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Q475qe1u9EM6NbRnVEvS1qwN6jVb5NkVp"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/N5i3rKlKMWglJfKzGE-g-FeTgGU>
Cc: IETF Disgust List <ietf@ietf.org>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2016 16:57:00 -0000

Hi Randy,

On 5/11/16 12:42 PM, Randy Bush wrote:
>> I would propose adding some text to this draft (probably as a
>> sub-section in section 2) that says that the SIA defined in RFC 6487 is
>> omitted when a certificate is used to sign RPSL objects.
> 
> perhaps you might also include your reasoning for this seemingly odd
> choice.

The SIA in 6487 mandates an rsync URI that points to the object that is
signed with the certificate. I am not aware of any RPSL servers that
support referencing an RPSL object via rsync.

> 
>> I agree that the original text allowing multiple signatures supports
>> the case where the components of the primary key of the object (i.e.,
>> prefix+ASN) come from different resource holders. I will restore that
>> text.
> 
> this is gonna be really simple; no complications at all i am sure.
> 
> btw, was this a consensus of the wg?

The original draft supported multiple signature attributes. During WG
review (WGLC?, don't recall), several people suggested simplifying the
approach by only allowing one signature attribute. Given the route[6]
example, we need multiple signatures modulo the proposed text to clarify
the handling/generation of those signatures.

Regards,
Brian