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

Tim Bruijnzeels <tim@ripe.net> Thu, 12 May 2016 11:29 UTC

Return-Path: <tim@ripe.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 64C9712D96E for <sidr@ietfa.amsl.com>; Thu, 12 May 2016 04:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 NeErkc6VPwv3 for <sidr@ietfa.amsl.com>; Thu, 12 May 2016 04:29:40 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9690412D97D for <sidr@ietf.org>; Thu, 12 May 2016 04:29:40 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1b0ooD-00026M-M8; Thu, 12 May 2016 13:29:39 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-233.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1b0ooD-000680-Ep; Thu, 12 May 2016 13:29:37 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <m24ma3ed16.wl%randy@psg.com>
Date: Thu, 12 May 2016 13:29:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A121B82-7C91-4A5E-A645-8A11C0DE647F@ripe.net>
References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> <m2shxoeeby.wl%randy@psg.com> <57336455.1040508@innovationslab.net> <m24ma3ed16.wl%randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3112)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --------
X-RIPE-Spam-Report: Spam Total Points: -8.1 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07192a47028c3adeb4479fdc204d516dbe82
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/SX6_Yrswo5o7Em871uvz-pz3bOc>
Cc: 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: Thu, 12 May 2016 11:29:42 -0000

> On 12 May 2016, at 13:22, Randy Bush <randy@psg.com> wrote:
> 
>>>> 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.
> 
> i.e. it was not wg consensus but you think you should do it anyway?

First off: I am sorry for arriving late to this party with my comments.

But regardless of process. For this to be useful for route objects we need two signatures in cases where the AS and prefix are held by different parties.

If the current text can't be modified, my guess is that a bis could be another option.

On another note: I think RPSL signatures on route objects add relatively little value - I would advise people to use ROAs instead. But the ability to sign over import/export in aut-num objects, or contact information/remarks etc in inetnum object to name two examples is useful, and only requires one signature.




> 
> randy
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr