Re: [sidr] WGLC for draft-ietf-sidr-slurm-04

Tim Bruijnzeels <tim@ripe.net> Mon, 17 April 2017 18:06 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 36F9E12894A; Mon, 17 Apr 2017 11:06:23 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 MjLr776e6SaC; Mon, 17 Apr 2017 11:06:21 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 C20DB13172A; Mon, 17 Apr 2017 11:06:20 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <tim@ripe.net>) id 1d0B2W-0008iP-Ql; Mon, 17 Apr 2017 20:06:18 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-148.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <tim@ripe.net>) id 1d0B2V-0001s5-Po; Mon, 17 Apr 2017 20:06:16 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com>
Date: Mon, 17 Apr 2017 15:06:02 -0300
Cc: sidr <sidr@ietf.org>, sidr chairs <sidr-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE73D619-1368-4A22-8FB1-D310F277D731@ripe.net>
References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com>
To: Sandra Murphy <sandy@tislabs.com>
X-Mailer: Apple Mail (2.3259)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07196a495a17c803f98c22a11b8331ffc1fd
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/DnfZP8qvEXfpNNivhCPR9arKq3c>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-slurm-04
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 17 Apr 2017 18:06:23 -0000

Dear WG

One thing the authors noted was that there may be discussion needed around the filtering of BGPSec assertions based on matching SKI - as the document currently says. This was added mainly in an attempt to make the spec feature complete and give an operator full freedom on filter rules.

SKIs use SHA-1. And recently it has been shown that SHA-1 collisions can be generated. This could lead one to believe that filtering of assertions based on a SKIs may not be a good idea. However, it should be noted that such collisions are probably irrelevant here. A ‘malicious' CA can always issue another router certificate for an existing (and requested) router certificate SKI and public key. So ‘collisions’ can exist anyway and a more secure hashing algorithm would not help.

The more fundamental question here is if it is really useful to have filtering based on the key itself - and if so - should it be possible to filter on the key alone (as the draft allows) or only in combination with an asserted ASN for that key (also allowed in this draft)?

As said it was mainly added for feature completeness, but it would be good to hear from this WG what the thoughts are. Personally I don’t see a big issue here - and would leave it to operators to use the options as they see fit.  But if there are concerns and there is no clear use case then I for one would be happy to take it out again in which case BGPSec assertions can only be filtered on matching ASN.

Cheers
Tim

> On 10 Apr 2017, at 17:49, Sandra Murphy <sandy@tislabs.com> wrote:
> 
> The authors of draft-ietf-sidr-slurm-04, "Simplified Local internet nUmber Resource Management with the RPKI”, have indicated that they believe the current version includes all wg comments and is mature and ready for working group last call.
> 
> This message starts a WGLC for draft-ietf-sidr-slurm-04.  The WGLC will end 24 April 2017.
> 
> The draft can be found at https://tools.ietf.org/html/draft-ietf-sidr-slurm-04 or https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/.
> 
> Please reply to the list whether the document is ready for publication or you have comments that you think should be addressed.
> 
> Please do read and respond to the list.  Remember that responses are required to gauge consensus, silence is not consent.
> 
> —Sandy, speaking as wg co-chair
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr