Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04

Mehmet Adalier <madalier@antarateknik.com> Wed, 21 June 2017 06:07 UTC

Return-Path: <madalier@antarateknik.com>
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 E0778131654 for <sidr@ietfa.amsl.com>; Tue, 20 Jun 2017 23:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level:
X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yahoo.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 cfO49aJowGol for <sidr@ietfa.amsl.com>; Tue, 20 Jun 2017 23:07:45 -0700 (PDT)
Received: from smtp104.biz.mail.bf1.yahoo.com (smtp104.biz.mail.bf1.yahoo.com [98.139.221.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7154E131632 for <sidr@ietf.org>; Tue, 20 Jun 2017 23:07:43 -0700 (PDT)
Received: (qmail 30496 invoked from network); 21 Jun 2017 06:07:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1498025262; bh=4gViRfMFUBTAS/vxUZfABwdUcft61XCwJ9HiXm7Jy1k=; h=Date:Subject:From:To:CC:Message-ID:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=hRQd1MqxdcMdatoiJb0nJXOXbJl0nbDt40vkZ6kmodADN2v25jeSpBKlYu8ZsoZV1d5szxdNhIPYz/IxcILumTQyTdj79fsBEzlKdsQp2zfepU3r6WdNGvjEg6pna/eEmZ08UwQYRYdZEdouoUVBb+dGS1ChFXdRAZjYf+LWiuQ=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: k0PgoAMVM1m7GSO1qUn9gAh8592oDNNh5Poeb_4rJJKlZad Jq4rt8SVsqgZjv09wVh1L2l3qXRwUvWDn85PAV7iU5r1bE96LUzdRMAobTEJ 6v9VEooQSIIBbBjkQGh9th3P9ucy8kz8Th4cUzlI70.LDKJ3mC3fzr8gMrbw _HoshgyUWf2XPS3Pjptl63JWFgg3sKbIpeduA7ToOPm2uS4z0NE1HXi0pLlL H.jL4QGfTLYorVodNo0SZJfIxB2BtJFET1WoUjVf8f.BXLMX47ai4brKVCWJ HRq4LIn0sEDnLtvDuAfonk5wnODvYBOcQ2VDTM_G2wg7p3HMXlXCcySQQHAn EHa2hvsXvJ67TN5.SJxOCvycHhLaXFa0H8d7Db0W.wf3kIrvwpGL_9aRAjxm 9GqOqyop0SMXoajLAvvnBQp1n48Obq0tpUkZtMz7o2guqSilQiU303O1pwVw UuGyR4ujI3G_uSSpOP7sNIAgRkBuuA5DV.bjwhmNxWM6Wx0THrwn5T4QvnRl Qc2I77me2uJ74Olu_HIsDOY..2qqtwKvTIL5QHvY9XG_Lq4.yzyY9MfFzSS9 7G.EONaeTi_OPAc5vnnuFhwG6zA--
X-Yahoo-SMTP: mGN28M.swBAqLrsVsMnMt.9fxF9UZFOhOQ--
User-Agent: Microsoft-MacOutlook/f.23.0.170610
Date: Tue, 20 Jun 2017 23:07:37 -0700
From: Mehmet Adalier <madalier@antarateknik.com>
To: Sandra Murphy <sandy@tislabs.com>, Christopher Morrow <morrowc.lists@gmail.com>
CC: sidr <sidr@ietf.org>, sidr chairs <sidr-chairs@ietf.org>
Message-ID: <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com>
Thread-Topic: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04
References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> <FE73D619-1368-4A22-8FB1-D310F277D731@ripe.net> <CAL9jLaYv-RZz8rzDy9XpjAsuVV4tFtxO33-0OjLQo2J00R60GA@mail.gmail.com> <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com>
In-Reply-To: <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/Hc7k-aJk832B3iFIbOzFCGV4puM>
Subject: Re: [sidr] once more with feeling! 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: Wed, 21 Jun 2017 06:07:53 -0000

In my opinion:

1) Irrelevant of the underlying hash function, BGPSec assertions based on “only with matching SKI” should not be recommended/possible
2)  Regarding keys, “only in combination with an asserted ASN for that key,” not on the key alone

mehmet

On 6/20/17, 8:38 PM, "sidr on behalf of Sandra Murphy" <sidr-bounces@ietf.org on behalf of sandy@tislabs.com> wrote:

    The “not have gotten much” was one request from an author, which got no response from the working group.
    
    Come on, folks.  We can do this.
    
    Maybe the usual increase in attention and energy of an approaching meeting will help.
    
    This starts a second wglc for draft-ietf-sidr-slurm-04.  Since it is the second wglc, it will be short, ending 30 Jun 2017.
    
    Silence is not consent.  Consensus for publication requires actual comment.  Read it.  Speak up.
    
    —Sandy, speaking as one of the wg co-chairs
    
    
    > On Jun 20, 2017, at 11:52 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
    > 
    > Howdy WG folks. this seems to not have gotten much review (after the authors changed a bunch).. can we get some readin/reviewin/commentin going on here please? :)
    > 
    > On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels <tim@ripe.net> wrote:
    > 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
    > 
    > _______________________________________________
    > sidr mailing list
    > sidr@ietf.org
    > https://www.ietf.org/mailman/listinfo/sidr
    > 
    
    _______________________________________________
    sidr mailing list
    sidr@ietf.org
    https://www.ietf.org/mailman/listinfo/sidr