From nobody Mon May 2 00:50:23 2016 Return-Path: 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 46DC712B039 for ; Mon, 2 May 2016 00:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sloc.de 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 xBqWrulYj9Qi for ; Mon, 2 May 2016 00:50:19 -0700 (PDT) Received: from mail.sloc.de (mail.sloc.de [178.63.28.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3AC12B023 for ; Mon, 2 May 2016 00:50:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sloc.de (Postfix) with ESMTP id 9897718815D6; Mon, 2 May 2016 09:50:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sloc.de Received: from mail.sloc.de ([127.0.0.1]) by localhost (sloc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIpO25nxwKTL; Mon, 2 May 2016 09:50:17 +0200 (CEST) Received: from [IPv6:2003:75:f51:c900:6c2d:341e:28f6:8623] (p200300750F51C9006C2D341E28F68623.dip0.t-ipconnect.de [IPv6:2003:75:f51:c900:6c2d:341e:28f6:8623]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sspies@sloc.de) by mail.sloc.de (Postfix) with ESMTPSA id 5412A18807C8; Mon, 2 May 2016 09:50:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sloc.de; s=201210; t=1462175417; bh=EYbcU4ONNp5pFQVBLi5RaGOxagEVrLKZ4bGEEnDOEdk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=XsTzXziVr/t0h44uPzxAs2DGZqTMf3ohfytsUw362msm2/pFnvZYY6iRfi7JiiKL3 xCzfpG9pTAUfbzGpldVBec6ld2nbP9EfL4fTmtcZdkmKeidWnHtNL3AS0IggfQGYos nL3i1g1BTrCggE7FpTAp6iNo5JUd6oWh3zkS0IiQ= Message-ID: <572706B5.9080704@sloc.de> Date: Mon, 02 May 2016 09:50:13 +0200 From: Sebastian spies User-Agent: Postbox 4.0.8 (Windows/20151105) MIME-Version: 1.0 To: Sandra Murphy References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Content-Type: multipart/alternative; boundary="------------080907090100070102030008" Archived-At: Cc: sidr Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 07:50:23 -0000 This is a multi-part message in MIME format. --------------080907090100070102030008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all, I support this Internet draft to be adopted as GROW working group document. Best regards, Sebastian Spies > Sandra Murphy > Mittwoch, 27. April 2016 14:11 > The authors have requested working group adoption for > draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin > Validation Results from a Route-Server to Peers”. > > This message starts an adoption call that will end in two weeks on 11 > May 2016. > > Please respond on the list to say whether you support adoption of this > work as a working group work item AND whether you will participate in > the discussion. > > Remember that working group consensus to adopt the work needs > responses, not just absence of objection, so speak up. > > The draft is available at > https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 > > —Sandy, speaking as one of the wg co-chairs > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------080907090100070102030008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi all,

I support this Internet draft to be adopted as GROW working group document.


Best regards,
Sebastian Spies



Mittwoch, 27. April 2016 14:11
The authors have requested working group adoption for draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin Validation Results from a Route-Server to Peers”.

This message starts an adoption call that will end in two weeks on 11 May 2016.

Please respond on the list to say whether you support adoption of this work as a working group work item AND whether you will participate in the discussion.

Remember that working group consensus to adopt the work needs responses, not just absence of objection, so speak up.

The draft is available at https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01

—Sandy, speaking as one of the wg co-chairs


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

--------------080907090100070102030008-- From nobody Mon May 2 01:54:36 2016 Return-Path: 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 06A3212D1C9 for ; Mon, 2 May 2016 01:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=franceix-net.20150623.gappssmtp.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 L-IXVlIjrXn0 for ; Mon, 2 May 2016 01:54:34 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 1B1B812D1C2 for ; Mon, 2 May 2016 01:54:33 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a17so131481629wme.0 for ; Mon, 02 May 2016 01:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=franceix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=asYC6NV9RRGbjNbNkR93yNbUxagUz8tJZOClJi2aEIU=; b=o6U3qzrF1SAMPcgTdpLeiUyQd1Sd/JOOH8JJL5ldycIXizhX66uTZIbRJfPKfS9IAD 7PEOvZvEIoP6+/ExT1YLlkHwIUrBU440gmqmFDvrLjkpPX/cppIzMcuYUIleGQexAWVM 44rt+wc/TTX7cAHM/U1iobBm5GD9JE7+kPNcLKo955mgXv+cduGknitV8p6lVzoG3fRm b5ZAwGGD9tCe0nlaCTnTyVhcIbm5hKgPojQjm2np+CYjihb6Xw1g5iXqRoZ7n4RfYmtN smfIncr6CSfZDaOL4ng4KMGBayjfjC2aafekdoYdytfQU0tzI/NYiiLe9X527Q+vIf/h 6ZlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=asYC6NV9RRGbjNbNkR93yNbUxagUz8tJZOClJi2aEIU=; b=gCZGYK6B234AiOv6zx2hyzcW/9AKGvA67ebEre2r2H4QS59j6ZpiG5hq0uaw6JaP07 qrk2O2rvOFagys5ctHzdVNgWcIIJqajWjzF14mIIS8parCC7XZPThhAJ7wGO54GhWC6R r6wOvOZEQ+J0gqeFbknhEKUCtzeh/SLLJn2zVZCqr3iiNL8xh9m6yqUcoEA1CVe7Eb2X vFdzqsaezcA6crl7+os5i0MZxgV78Isell3k817rBw15JUXv4cyPA3zFAqBRmgxvIFfK /Zz7UYXf/pa1zTzrvPcqYwywcMpczkulngfXPVyGq9orLK3+KU6RO8qbizNFRyvJ32qb f2CA== X-Gm-Message-State: AOPr4FX9vWAyWTgD1eHDjouMop/cOREUoQuSkWac7SQyTnAHYHMvu9IjHs1JX0p7jrXoUQ== X-Received: by 10.28.169.11 with SMTP id s11mr18568025wme.62.1462179271615; Mon, 02 May 2016 01:54:31 -0700 (PDT) Received: from [192.168.1.31] (LMontsouris-657-1-2-103.w90-63.abo.wanadoo.fr. [90.63.237.103]) by smtp.gmail.com with ESMTPSA id 8sm17688216wms.14.2016.05.02.01.54.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 01:54:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Arnaud Fenioux In-Reply-To: <572706B5.9080704@sloc.de> Date: Mon, 2 May 2016 10:54:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45E3826E-E264-48E7-8FF3-2B20A9444DFF@franceix.net> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <572706B5.9080704@sloc.de> To: sidr , Sandra Murphy X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 08:54:36 -0000 Hi all, I support the adoption of this work as a working group work item and I = will participate in the discussion. (I=92m also one of the authors). Regards, -- Arnaud Fenioux Network Engineer - FranceIX > On 2 May 2016, at 09:50, Sebastian spies = wrote: >=20 > Hi all, >=20 > I support this Internet draft to be adopted as GROW working group = document. >=20 >=20 > Best regards, > Sebastian Spies >=20 >=20 >=20 >> Sandra Murphy Mittwoch, 27. April 2016 14:11 >> The authors have requested working group adoption for = draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin = Validation Results from a Route-Server to Peers=94. >>=20 >> This message starts an adoption call that will end in two weeks on 11 = May 2016. >>=20 >> Please respond on the list to say whether you support adoption of = this work as a working group work item AND whether you will participate = in the discussion. >>=20 >> Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >>=20 >> The draft is available at = https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 >>=20 >> =97Sandy, speaking as one of the wg co-chairs >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon May 2 02:41:21 2016 Return-Path: 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 ECEB612D0DA for ; Mon, 2 May 2016 02:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 jnl0b-fEYZjC for ; Mon, 2 May 2016 02:41:16 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix-1.ams-ix.net [185.55.136.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703E112D0CD for ; Mon, 2 May 2016 02:41:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from [IPv6:2001:67c:1a8:102:56d:5400:5f9a:3f24] (unknown [IPv6:2001:67c:1a8:102:56d:5400:5f9a:3f24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: aristidis) by deliverix.ams-ix.net (Postfix) with ESMTPSA id CFBDC46533; Mon, 2 May 2016 11:41:14 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aris Lambrianidis In-Reply-To: <45E3826E-E264-48E7-8FF3-2B20A9444DFF@franceix.net> Date: Mon, 2 May 2016 11:41:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BC0FE21-93CD-4316-BC01-B946B9CE6081@ams-ix.net> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <572706B5.9080704@sloc.de> <45E3826E-E264-48E7-8FF3-2B20A9444DFF@franceix.net> To: SIDR IETF mailing list X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:41:19 -0000 Greetings, As a co-author, I support the adoption and will participate in the = discussion. Kind regards, Aris Lambrianidis > On 02 May 2016, at 10:54, Arnaud Fenioux = wrote: >=20 > Hi all, >=20 > I support the adoption of this work as a working group work item and I = will participate in the discussion. > (I=92m also one of the authors). >=20 > Regards, >=20 > -- > Arnaud Fenioux > Network Engineer - FranceIX >=20 >=20 >> On 2 May 2016, at 09:50, Sebastian spies = wrote: >>=20 >> Hi all, >>=20 >> I support this Internet draft to be adopted as GROW working group = document. >>=20 >>=20 >> Best regards, >> Sebastian Spies >>=20 >>=20 >>=20 >>> Sandra Murphy Mittwoch, 27. April 2016 14:11 >>> The authors have requested working group adoption for = draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin = Validation Results from a Route-Server to Peers=94. >>>=20 >>> This message starts an adoption call that will end in two weeks on = 11 May 2016. >>>=20 >>> Please respond on the list to say whether you support adoption of = this work as a working group work item AND whether you will participate = in the discussion. >>>=20 >>> Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >>>=20 >>> The draft is available at = https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 >>>=20 >>> =97Sandy, speaking as one of the wg co-chairs >>>=20 >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon May 2 06:32:58 2016 Return-Path: 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 7697B12D0B6 for ; Mon, 2 May 2016 06:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 fMLRp2G3jqft for ; Mon, 2 May 2016 06:32:54 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 89263128B44 for ; Mon, 2 May 2016 06:32:54 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id xk12so2807750pac.0 for ; Mon, 02 May 2016 06:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=nwfKx1mur7HAGWm2954ZPsufVkZqHhMBw9rscO5PmXA=; b=nAyvBJ5QrTs2/uwhuwD+7t7mnmdamChjn8i7AiirQ6pKm1WfLCmnUsdZnIv2JQp2MI pJ4r/xDK4xwv6VZ/u0Y11PC+FH03nMGMLQO5zuFkhbjlx3xfrZKkTbZOY9k9TnB6I7mb pKzjuHyC9PddUGL6ICPxL7Idhoz2WBPTaJ00am4eFOrrh2/RJKjvqfNVYKORK8SapY9H YSqvI/6BoJk3qd7rB4V2wHI3l006YSeRTyghbLVIEoImZ/00NB+pbif4bMKpVIpYmiX4 tUGWdGYJl9Mo6js6iObJAVWCKkrzhus0ZI0LeWOu1d1ge/I1JevQa9RqUHD2CcFpqvB+ hg7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nwfKx1mur7HAGWm2954ZPsufVkZqHhMBw9rscO5PmXA=; b=QREt+7ESn4j0Y5e9HxJAjgj4Ju/j1bCUAKRsoljOB9S3Z6tYEMN+TQBr1PxI0cTEbZ AmTwIHaUYWgL0AG/KGG5SRPw18BFVxVqCT1QURFjfMHuWyOicyUfEZ+LjxZWqKKLeDXe dFuzVjU1WmtG4lSurlR3AQ5WFa6l5DgpXkSTa9E7Qczh4WWcXfzhBT+C5loWVAX5Dnru M2ftguhBMlVWfUr01e/MSZZaw8+KsLObOM1zjVcwU3xrvVtbGzbPxiunFa2JbPYccs4a +UKMU49r+osOmTj3bvNBKiFKBqhaSMTNA2SKqcrilERpUMcEhPiopRJ3GL4RzJkt20gj qO0Q== X-Gm-Message-State: AOPr4FVgs2+bdmQ4W0sd734f/yNZplqG6IZb+PP772bXqeejJA8QV4Z7JO3fiT8q1+VFng== X-Received: by 10.66.1.135 with SMTP id 7mr17334091pam.106.1462195974045; Mon, 02 May 2016 06:32:54 -0700 (PDT) Received: from [190.112.53.83] ([190.112.53.83]) by smtp.googlemail.com with ESMTPSA id w125sm21518815pfb.53.2016.05.02.06.32.51 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 06:32:52 -0700 (PDT) References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> To: sidr@ietf.org From: "Carlos M. Martinez" Message-ID: <572756FF.8030406@gmail.com> Date: Mon, 2 May 2016 09:32:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:32:56 -0000 Hello all, LACNIC has worked on three projects involving RPKI-enabling IXPs [0]. We certainly support adoption of this document as a WG item and will participate in the discussion. Thanks! -Carlos [0] https://tools.ietf.org/html/draft-fmejia-opsec-origin-a-country-02 On 4/27/16 8:11 AM, Sandra Murphy wrote: > The authors have requested working group adoption for draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin Validation Results from a Route-Server to Peers”. > > This message starts an adoption call that will end in two weeks on 11 May 2016. > > Please respond on the list to say whether you support adoption of this work as a working group work item AND whether you will participate in the discussion. > > Remember that working group consensus to adopt the work needs responses, not just absence of objection, so speak up. > > The draft is available at https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 > > —Sandy, speaking as one of the wg co-chairs > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Mon May 2 10:04:19 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2E812D5A3; Mon, 2 May 2016 10:04:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 10:04:17 -0700 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 17:04:17 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sidr-as-migration-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm wondering a few things that I think are important to discuss. If this is all fine, I may have more comments as I think I'll need to dig into the BGPsec draft first and then this one again. 1. Why is this document preceding the BGP spec? Shouldn't this be part of the BGPSec protocol document? If BGPSec isn't getting deployed because of the AS path migration problem and this gets us a little further, but not quite as secure, maybe that's a trade off we need to accept. But this document coming through first is a little concerning even though the protocol spec is a normative reference. 2. The introduction makes this sound rather innocuous, but the security considerations section is more explicit that this is a work around BGPSec and isn't quite as secure. I'd like to see some text explaining this better in the introduction, more similar to what's in the first paragraph of the security considerations section. Thank you From nobody Mon May 2 10:25:32 2016 Return-Path: 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 A0F6A12D5B6 for ; Mon, 2 May 2016 10:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable 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 IlnSDzS2U8iu for ; Mon, 2 May 2016 10:25:20 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 B73B412D5A3 for ; Mon, 2 May 2016 10:25:19 -0700 (PDT) Received: from mb-2.local ([IPv6:2620:11a:c081:20:a030:db95:70f3:fa37]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u42HPHlW021668 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 2 May 2016 17:25:17 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:a030:db95:70f3:fa37] claimed to be mb-2.local To: Kathleen Moriarty , The IESG References: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: <086783f7-b260-d12c-927b-adfb5cbd4a12@bogus.com> Date: Mon, 2 May 2016 10:25:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1 MIME-Version: 1.0 In-Reply-To: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jjn8fSikki0rqJ6PKDdL10AASBjMu0b6l" Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 17:25:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jjn8fSikki0rqJ6PKDdL10AASBjMu0b6l Content-Type: multipart/mixed; boundary="DBP59l0owst07SkusIjQe3rhNu9x3rGwo" From: joel jaeggli To: Kathleen Moriarty , The IESG Cc: morrowc@ops-netman.net, aretana@cisco.com, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Message-ID: <086783f7-b260-d12c-927b-adfb5cbd4a12@bogus.com> Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) References: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> In-Reply-To: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> --DBP59l0owst07SkusIjQe3rhNu9x3rGwo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/2/16 10:04 AM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-sidr-as-migration-05: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm wondering a few things that I think are important to discuss. If > this is all fine, I may have more comments as I think I'll need to dig > into the BGPsec draft first and then this one again. >=20 > 1. Why is this document preceding the BGP spec? Shouldn't this be par= t > of the BGPSec protocol document? If BGPSec isn't getting deployed > because of the AS path migration problem and this gets us a little > further, but not quite as secure, maybe that's a trade off we need to > accept. But this document coming through first is a little concerning > even though the protocol spec is a normative reference.=20 I have a lot of trouble imagining that this one could usefully be published without the other. > 2. The introduction makes this sound rather innocuous, but the securit= y > considerations section is more explicit that this is a work around BGPS= ec > and isn't quite as secure. I'd like to see some text explaining this > better in the introduction, more similar to what's in the first paragra= ph > of the security considerations section. >=20 > Thank you >=20 >=20 >=20 >=20 --DBP59l0owst07SkusIjQe3rhNu9x3rGwo-- --jjn8fSikki0rqJ6PKDdL10AASBjMu0b6l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlcnjX4ACgkQ8AA1q7Z/VrJmUgCfS7hAp3NIdsPvTHgg0NXgBGKD a7cAoIv8cpMGuglPJ8e6Ryd3Gz/qrzQf =Oorm -----END PGP SIGNATURE----- --jjn8fSikki0rqJ6PKDdL10AASBjMu0b6l-- From nobody Mon May 2 12:28:43 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 240B112D17D; Mon, 2 May 2016 12:28:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502192842.15850.89511.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 12:28:42 -0700 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Alia Atlas' Yes on draft-ietf-sidr-as-migration-05: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 19:28:42 -0000 Alia Atlas has entered the following ballot position for draft-ietf-sidr-as-migration-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I will note that progressing this as Standards track does presume that BGsec will also progress as Standards track, or that there will be a downref from PS to Experimental. From nobody Mon May 2 12:32:14 2016 Return-Path: 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 62ECF12D186; Mon, 2 May 2016 12:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 gmfZVV9_-R5H; Mon, 2 May 2016 12:32:05 -0700 (PDT) Received: from cdcipgw02.twcable.com (unknown [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id B466A12D179; Mon, 2 May 2016 12:32:01 -0700 (PDT) X-SENDER-IP: 10.64.163.148 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.24,568,1454994000"; d="scan'208";a="569454562" Received: from unknown (HELO exchpapp07.corp.twcable.com) ([10.64.163.148]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 02 May 2016 15:27:41 -0400 Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp07.corp.twcable.com (10.64.163.148) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 2 May 2016 15:31:59 -0400 Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by EXCHPAPP06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1156.000; Mon, 2 May 2016 15:31:59 -0400 From: "George, Wes" To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) Thread-Index: AQHRpKlL8w4OyrwpLUqKjugsycoM6w== Date: Mon, 2 May 2016 19:31:59 +0000 Message-ID: References: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> In-Reply-To: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22296.005 x-tm-as-result: No--41.580600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <730886B3AA756040AB08BAB5C75F4C12@twcable.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "morrowc@ops-netman.net" , "draft-ietf-sidr-as-migration@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 19:32:07 -0000 DQpPbiA1LzIvMTYsIDE6MDQgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSIgPEthdGhsZWVuLk1vcmlh cnR5LmlldGZAZ21haWwuY29tPg0Kd3JvdGU6DQoNCg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5ESVND VVNTOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4xLiAgV2h5IGlzIHRoaXMgZG9jdW1lbnQgcHJlY2Vk aW5nIHRoZSBCR1Agc3BlYz8gIFNob3VsZG4ndCB0aGlzIGJlIHBhcnQNCj5vZiB0aGUgQkdQU2Vj IHByb3RvY29sIGRvY3VtZW50PyAgSWYgQkdQU2VjIGlzbid0IGdldHRpbmcgZGVwbG95ZWQNCj5i ZWNhdXNlIG9mIHRoZSBBUyBwYXRoIG1pZ3JhdGlvbiBwcm9ibGVtIGFuZCB0aGlzIGdldHMgdXMg YSBsaXR0bGUNCj5mdXJ0aGVyLCBidXQgbm90IHF1aXRlIGFzIHNlY3VyZSwgbWF5YmUgdGhhdCdz IGEgdHJhZGUgb2ZmIHdlIG5lZWQgdG8NCj5hY2NlcHQuICBCdXQgdGhpcyBkb2N1bWVudCBjb21p bmcgdGhyb3VnaCBmaXJzdCBpcyBhIGxpdHRsZSBjb25jZXJuaW5nDQo+ZXZlbiB0aG91Z2ggdGhl IHByb3RvY29sIHNwZWMgaXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlLg0KDQpXR10gVGhpcyBpcyBs YXJnZWx5IGEgdGltaW5nIHByb2JsZW0uIFRoZSBwcm90b2NvbCBkcmFmdCB3YXMgd3JpdHRlbg0K Zmlyc3QsIGJ1dCBhZnRlciB0aGlzIGlzc3VlIHdhcyBpZGVudGlmaWVkLCBBUy1taWdyYXRpb24g d2FzIHdyaXR0ZW4sIGFuZA0KYm90aCBkcmFmdHMgd2VyZSByZXZpc2VkIGFuZCByZXZpZXdlZCBp biBwYXJhbGxlbC4NClRoZSBXRyBkaXNjdXNzZWQgaW50ZWdyYXRpbmcgQVMtbWlncmF0aW9uIGlu dG8gdGhlIHByb3RvY29sIHNwZWMsIGFuZA0KZGVjaWRlZCB0byBrZWVwIGl0IHNlcGFyYXRlLiBB dCB0aGUgdGltZSwgdGhpcyB3YXMgZHVlIHRvIHNldmVyYWwNCmRlcGVuZGVuY2llcyBhbmQgYXNz dW1wdGlvbnM6DQpGaXJzdCwgdGhlIFdHIGNvbnNlbnN1cyBiZXR3ZWVuIFNJRFIsIEdST1csIGFu ZCBSVEdXRyB3YXMgdGhhdCBCR1BTZWMNCmRlZmluaXRlbHkgbmVlZGVkIHRvIGFsbG93IGZvciBB Uy1NaWdyYXRpb24sIGJ1dCBiZWZvcmUgQkdQU2VjIGNvdWxkIGJlDQpleHBlY3RlZCB0byBzdXBw b3J0IEFTLU1pZ3JhdGlvbiwgdGhvc2UgdG9vbHMgbmVlZGVkIHRvIGJlIGRvY3VtZW50ZWQgYXMg YQ0KZm9ybWFsIHBhcnQgb2YgdGhlIEJHUCBwcm90b2NvbCAoaW4gUlRHV0cpLCByYXRoZXIgdGhh biBqdXN0IGJlaW5nIGRlDQpmYWN0byBzdGFuZGFyZCBvbiBhY2NvdW50IG9mIHRoZWlyIGJlaW5n IGltcGxlbWVudGVkIGJ5IGFsbCBtYWpvciByb3V0ZXINCnZlbmRvcnMgYW5kIHdpZGVseSB1c2Vk IGJ5IElTUHMuIFRoYXQgcmVzdWx0ZWQgaW4gUkZDIDc3MDUgKGFrYQ0KaWRyLWFzLW1pZ3JhdGlv biksIGFsc28gd3JpdHRlbiBsYXJnZWx5IGluIHBhcmFsbGVsIHdpdGggc2lkci1hcy1taWdyYXRp b24NCihpbiBmYWN0IHRoZXkgc3RhcnRlZCBhcyBvbmUgZG9jdW1lbnQgYW5kIHdlcmUgc3BsaXQp Lg0KU2Vjb25kLCB0aGUgQkdQU2VjIHByb3RvY29sIGRvY3VtZW50IHdhcyB0aG91Z2h0IHRvIGJl IG11Y2ggY2xvc2VyIHRvDQpjb21wbGV0aW9uIGFuZCBwdWJsaXNoaW5nIHRoYW4gZWl0aGVyIG9m IHRoZXNlIGRvY3VtZW50cywgYW5kIHdhcyBleHBlY3RlZA0KdG8gYmUgY29tcGxldGVkIHdlbGwg cHJpb3IgdG8gc2lkci1hcy1taWdyYXRpb24gc3VjaCB0aGF0IGl0IGRpZG4ndCBtYWtlDQptdWNo IHNlbnNlIHRvIGRlbGF5IHRoZSBwcm90b2NvbCBkb2MgdG8gaW50ZWdyYXRlIHRoZW0uDQpJbiB0 aGUgbWVhbnRpbWUsIHRoZSBwcm90b2NvbCBkb2N1bWVudCB1bmRlcndlbnQgYWRkaXRpb25hbCBy ZXZpZXdzIHRoYXQNCnVuY292ZXJlZCBpc3N1ZXMgcmVxdWlyaW5nIG1vcmUgc2lnbmlmaWNhbnQg cmV2aXNpb24gYW5kIGRlbGF5ZWQgaXRzDQpwcm9ncmVzcyBzdWNoIHRoYXQgdGhlIGFzLW1pZ3Jh dGlvbiBkb2N1bWVudCBpcyBub3cgcmVhZHkgZmlyc3QuIFRoZQ0KcHJvdG9jb2wgZG9jdW1lbnQg aGFzIGhhZCBlZGl0cyB0byBlbnN1cmUgcHJvcGVyIGludGVncmF0aW9uIGJldHdlZW4gdGhlDQp0 d28gZG9jdW1lbnRzIHdoZXJlIGFwcHJvcHJpYXRlIChhZGRpbmcgY2xhcml0eSB2aWEgcmVmZXJl bmNlcyBhbmQNCmxhbmd1YWdlIHRvIGVuc3VyZSBubyBjb25mbGljdCBpbiB3aGF0IGlzIGJlaW5n IGRpcmVjdGVkIGluIGVhY2ggc3RhbmRhcmQpLg0KTGFzdCwgcGFydCBvZiB0aGUgcmF0aW9uYWxl IGZvciBrZWVwaW5nIHRoZW0gc2VwYXJhdGUgaXMgdGhhdCB3aGlsZSB0aGUgV0cNCnN0cm9uZ2x5 IHJlY29tbWVuZHMgdGhhdCBib3RoIHBhcnRzIGJlIGltcGxlbWVudGVkLCBCR1BTZWMgZG9lcyBu b3QNCnN0cmljdGx5IHJlcXVpcmUgdGhlIGFkZGl0aW9uYWwgc3VwcG9ydCBmb3IgQVMtbWlncmF0 aW9uIChJLmUuDQpJbXBsZW1lbnRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBpbiBCR1BT ZWMgcHJvdG9jb2wgZG9jdW1lbnQgaXMgYQ0KTVVTVCwgQVMtbWlncmF0aW9uIGlzIGEgU0hPVUxE KSwgYW5kIHRodXMgaGF2aW5nIHRoZSBkb2N1bWVudHMgYmUgc2VwYXJhdGUNCm1ha2VzIGEgY2xl YXIgZGlzdGluY3Rpb24gYmV0d2VlbiBiYXNpYyBwcm90b2NvbCBmdW5jdGlvbiBhbmQgYWRkLW9u DQpmZWF0dXJlcy4NCg0KPg0KPg0KPjIuICBUaGUgaW50cm9kdWN0aW9uIG1ha2VzIHRoaXMgc291 bmQgcmF0aGVyIGlubm9jdW91cywgYnV0IHRoZSBzZWN1cml0eQ0KPmNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gaXMgbW9yZSBleHBsaWNpdCB0aGF0IHRoaXMgaXMgYSB3b3JrIGFyb3VuZCBCR1BTZWMN Cj5hbmQgaXNuJ3QgcXVpdGUgYXMgc2VjdXJlLiAgSSdkIGxpa2UgdG8gc2VlIHNvbWUgdGV4dCBl eHBsYWluaW5nIHRoaXMNCj5iZXR0ZXIgaW4gdGhlIGludHJvZHVjdGlvbiwgbW9yZSBzaW1pbGFy IHRvIHdoYXQncyBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoDQo+b2YgdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24uDQoNCldHXSBUaGUgaW50ZW50IHdhcyBub3QgdG8gaW1wbHkgdGhh dCBCR1BTZWMgd2l0aCBBUy1NaWdyYXRpb24gc3VwcG9ydCBpcw0KZnVuZGFtZW50YWxseSBsZXNz IHNlY3VyZSB0aGFuIEJHUFNlYyB3aXRob3V0IGl0LCBzbyBpZiB0aGF0J3Mgd2hhdCB3ZSdyZQ0K Y29udmV5aW5nIGJldHdlZW4gdGhlIHR3byBzZWN0aW9ucywgSSdkIGFwcHJlY2lhdGUgYWRkaXRp b25hbCBndWlkYW5jZSBvbg0Kd2hhdCBzcGVjaWZpY2FsbHkgaXMgZ2l2aW5nIHlvdSB0aGF0IGlt cHJlc3Npb24uIEl0J3Mgbm90IHJlYWxseSBhDQp3b3JrLWFyb3VuZCBCR1BTZWMgYXMgbXVjaCBh cyBpdCdzIG9ic2VydmluZyB0aGF0IHRoZSBCR1BTZWMgcHJvdG9jb2wgYXMNCndyaXR0ZW4gd291 bGQgYnJlYWsgdGhpcyBjb21tb24gbWV0aG9kIGZvciBBUy1NaWdyYXRpb24sIGFuZCB0aGlzIGRv Y3VtZW50DQphZGRyZXNzZXMgdGhhdCBnYXAgYnkgZW5zdXJpbmcgdGhhdCBpdCBjYW4gYmUgZG9u ZSB3aXRoaW4gdGhlIHNlY3VyaXR5DQpmcmFtZXdvcmsgcHJvdmlkZWQgYnkgQkdQU2VjLg0KDQoN ClRoYW5rcywNCg0KV2VzIEdlb3JnZQ0KDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMg YmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSQ0KaGF2ZSBubyBjb250 cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Tue May 3 02:55:45 2016 Return-Path: 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 5F6AE12D6C1 for ; Tue, 3 May 2016 02:55:44 -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 w6bmxszRjBUK for ; Tue, 3 May 2016 02:55:42 -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 B09C812D146 for ; Tue, 3 May 2016 02:55:42 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1axX3K-0002io-OJ; Tue, 03 May 2016 11:55:40 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-122.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1axX3K-0004qx-HX; Tue, 03 May 2016 11:55:38 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: <572756FF.8030406@gmail.com> Date: Tue, 3 May 2016 11:55:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9864FF77-D431-43F1-9077-E8A557053BC0@ripe.net> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <572756FF.8030406@gmail.com> To: carlos@lacnic.net X-Mailer: Apple Mail (2.3112) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.0 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: 784d7acfe6559f2a0b602ec6519a0719841ff2e469879134a9d9618886c107b1 Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 09:55:44 -0000 Hi, I believe this is useful work and support adoption. Happy to contribute = to the discussion where I can. Tim > On 02 May 2016, at 15:32, Carlos M. Martinez = wrote: >=20 > Hello all, >=20 > LACNIC has worked on three projects involving RPKI-enabling IXPs [0]. = We > certainly support adoption of this document as a WG item and will > participate in the discussion. >=20 > Thanks! >=20 > -Carlos >=20 > [0] https://tools.ietf.org/html/draft-fmejia-opsec-origin-a-country-02 >=20 > On 4/27/16 8:11 AM, Sandra Murphy wrote: >> The authors have requested working group adoption for = draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin = Validation Results from a Route-Server to Peers=94. >>=20 >> This message starts an adoption call that will end in two weeks on 11 = May 2016. >>=20 >> Please respond on the list to say whether you support adoption of = this work as a working group work item AND whether you will participate = in the discussion. >>=20 >> Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >>=20 >> The draft is available at = https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 >>=20 >> =97Sandy, speaking as one of the wg co-chairs >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue May 3 03:31:10 2016 Return-Path: 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 CFAD412D71D; Tue, 3 May 2016 03:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 KX-aX_Dnjt20; Tue, 3 May 2016 03:31:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EBE12D715; Tue, 3 May 2016 03:31:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91181BE5C; Tue, 3 May 2016 11:31:03 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeYlV9f7xNSC; Tue, 3 May 2016 11:31:01 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 15BABBE57; Tue, 3 May 2016 11:31:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462271461; bh=Cb8BX9zjJEBCGYB5/lA3SoskDSx9EiqJnYpcdo1xjFY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=AWmYu+DrmeE3dio7N1wIDfi9fJw4/i7CpUZ0nQymScb/znvtB5dJCFsh5H5BgnsSp P5qhyMOa/UxIQrEDM44JnWTrSYOWp9WVOqk2iK5rriO6PSKsGHf8cdUxOWkKxA242r aYbmGkmOCBryEbhwY7gXeSFnEoS+hopzVo92Kyv4= To: "George, Wes" , Kathleen Moriarty , The IESG References: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57287DE3.9000604@cs.tcd.ie> Date: Tue, 3 May 2016 11:30:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080909020108040205020105" Archived-At: Cc: "morrowc@ops-netman.net" , "draft-ietf-sidr-as-migration@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 10:31:09 -0000 This is a cryptographically signed message in MIME format. --------------ms080909020108040205020105 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Wes, (FWIW, I agree with Kathleen's DISCUSS on this but one question below before I post my own ballot...) On 02/05/16 20:31, George, Wes wrote: >=20 > On 5/2/16, 1:04 PM, "Kathleen Moriarty" > wrote: >=20 >=20 >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> 1. Why is this document preceding the BGP spec? Shouldn't this be pa= rt >> of the BGPSec protocol document? If BGPSec isn't getting deployed >> because of the AS path migration problem and this gets us a little >> further, but not quite as secure, maybe that's a trade off we need to >> accept. But this document coming through first is a little concerning= >> even though the protocol spec is a normative reference. >=20 > WG] This is largely a timing problem. The protocol draft was written > first, but after this issue was identified, AS-migration was written, a= nd > both drafts were revised and reviewed in parallel. > The WG discussed integrating AS-migration into the protocol spec, and > decided to keep it separate. At the time, this was due to several > dependencies and assumptions: > First, the WG consensus between SIDR, GROW, and RTGWG was that BGPSec > definitely needed to allow for AS-Migration, but before BGPSec could be= > expected to support AS-Migration, those tools needed to be documented a= s a > formal part of the BGP protocol (in RTGWG), rather than just being de > facto standard on account of their being implemented by all major route= r > vendors and widely used by ISPs. That resulted in RFC 7705 (aka > idr-as-migration), also written largely in parallel with sidr-as-migrat= ion > (in fact they started as one document and were split). > Second, the BGPSec protocol document was thought to be much closer to > completion and publishing than either of these documents, and was expec= ted > to be completed well prior to sidr-as-migration such that it didn't mak= e > much sense to delay the protocol doc to integrate them. > In the meantime, the protocol document underwent additional reviews tha= t > uncovered issues requiring more significant revision and delayed its > progress such that the as-migration document is now ready first. The > protocol document has had edits to ensure proper integration between th= e > two documents where appropriate (adding clarity via references and > language to ensure no conflict in what is being directed in each standa= rd). > Last, part of the rationale for keeping them separate is that while the= WG > strongly recommends that both parts be implemented, BGPSec does not > strictly require the additional support for AS-migration (I.e. > Implementing the functionality defined in BGPSec protocol document is a= > MUST, AS-migration is a SHOULD), and thus having the documents be separ= ate > makes a clear distinction between basic protocol function and add-on > features. This is only a timing problem if bgpsec doesn't change in some incompatible manner. If such a change happens then this is more than a timing issue. What'd be bad about just holding this in the WG until bgpsec is ready? Since there's a normative reference anyway getting the IESG to approve both at once seems like it'd be better. Cheers, S. >=20 >> >> >> 2. The introduction makes this sound rather innocuous, but the securi= ty >> considerations section is more explicit that this is a work around BGP= Sec >> and isn't quite as secure. I'd like to see some text explaining this >> better in the introduction, more similar to what's in the first paragr= aph >> of the security considerations section. >=20 > WG] The intent was not to imply that BGPSec with AS-Migration support i= s > fundamentally less secure than BGPSec without it, so if that's what we'= re > conveying between the two sections, I'd appreciate additional guidance = on > what specifically is giving you that impression. It's not really a > work-around BGPSec as much as it's observing that the BGPSec protocol a= s > written would break this common method for AS-Migration, and this docum= ent > addresses that gap by ensuring that it can be done within the security > framework provided by BGPSec. >=20 >=20 > Thanks, >=20 > Wes George >=20 >=20 > Anything below this line has been added by my company=E2=80=99s mail se= rver, I > have no control over it. > ----------- >=20 >=20 >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable pr= oprietary information, which is privileged, confidential, or subject to c= opyright belonging to Time Warner Cable. This E-mail is intended solely f= or the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified tha= t any dissemination, distribution, copying, or action taken in relation t= o the contents of and attachments to this E-mail is strictly prohibited a= nd may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any co= py of this E-mail and any printout. >=20 --------------ms080909020108040205020105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDMx MDMwNTlaMC8GCSqGSIb3DQEJBDEiBCBiQR+KYkQhlnllSnbJMYovc58q7bWmv3tiqPBlulLv FDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBnoqsQc+gDvhE382QAfyVjRykdHDaPjISQMqfzSd2Xp05kdhRz6Kta HUeAOAxWClPfyMZaGx4O2qOsi2di6KDZDGmzBmFzRK2TP/h4q9i83oXurT6aKP+SXFqBcsOY wphbxTQoz9r0rC7dmTahm/YSreygcmIbn/fyotT33poQ98juJFtJYEizNuFfqMbaJpEHIVOM O03JxR9pSzwcl8xWAlq0jHPrG5EyuI47xobhTDgqGJ8tUG6qy/sfXtN3xaZfh0u5x7uKrz/f PWccm3S6gvLJWp82h62dQZXJBOSTGg80aVHKY4mmxILGBqGsUW5yos9NUVsUn3Ax5FXDkdnX AAAAAAAA --------------ms080909020108040205020105-- From nobody Tue May 3 07:03:53 2016 Return-Path: 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 CAB4712D814; Tue, 3 May 2016 07:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 MjayHpBxHVlj; Tue, 3 May 2016 07:03:45 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id CE4E312D0AC; Tue, 3 May 2016 07:03:34 -0700 (PDT) X-SENDER-IP: 10.64.163.148 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.24,572,1454994000"; d="scan'208";a="1270849783" Received: from unknown (HELO exchpapp07.corp.twcable.com) ([10.64.163.148]) by cdpipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 03 May 2016 09:58:04 -0400 Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp07.corp.twcable.com (10.64.163.148) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 3 May 2016 10:02:58 -0400 Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by EXCHPAPP06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1156.000; Tue, 3 May 2016 10:02:58 -0400 From: "George, Wes" To: Stephen Farrell , Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) Thread-Index: AQHRpUR/8w4OyrwpLUqKjugsycoM6w== Date: Tue, 3 May 2016 14:02:58 +0000 Message-ID: References: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> <57287DE3.9000604@cs.tcd.ie> In-Reply-To: <57287DE3.9000604@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22296.005 x-tm-as-result: No--45.489900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <25719B7C5068C74E83119FFB19A2612B@twcable.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "morrowc@ops-netman.net" , "draft-ietf-sidr-as-migration@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:03:48 -0000 DQpPbiA1LzMvMTYsIDY6MzAgQU0sICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPiB3cm90ZToNCg0KPg0KPkhpIFdlcywNCj4NCj5UaGlzIGlzIG9ubHkgYSB0aW1p bmcgcHJvYmxlbSBpZiBiZ3BzZWMgZG9lc24ndCBjaGFuZ2UgaW4gc29tZQ0KPmluY29tcGF0aWJs ZSBtYW5uZXIuIElmIHN1Y2ggYSBjaGFuZ2UgaGFwcGVucyB0aGVuIHRoaXMgaXMgbW9yZQ0KPnRo YW4gYSB0aW1pbmcgaXNzdWUuDQo+V2hhdCdkIGJlIGJhZCBhYm91dCBqdXN0IGhvbGRpbmcgdGhp cyBpbiB0aGUgV0cgdW50aWwgYmdwc2VjIGlzDQo+cmVhZHk/IFNpbmNlIHRoZXJlJ3MgYSBub3Jt YXRpdmUgcmVmZXJlbmNlIGFueXdheSBnZXR0aW5nIHRoZQ0KPklFU0cgdG8gYXBwcm92ZSBib3Ro IGF0IG9uY2Ugc2VlbXMgbGlrZSBpdCdkIGJlIGJldHRlci4NCg0KV0ddIFdlbGwsIEkgZG9uJ3Qg dGhpbmsgdGhlIEJHUFNlYyBwcm90b2NvbCBkcmFmdCBpcyByZWFsbHkgZmFyIGVub3VnaA0KYmVo aW5kIHRoYXQgaG9sZGluZyB0aGlzIG9uZSB3b3VsZCBtYWtlIG11Y2ggZGlmZmVyZW5jZSBpbiB0 aGUgb3V0Y29tZS4gTXkNCmNvLWF1dGhvciAoYW5kIFdHIENoYWlyKSByZXBsaWVkIGluIGFub3Ro ZXIgdGhyZWFkIHRoYXQgdGhlIEJHUFNlYyBkb2MgaXMNCnBhc3QgV0dMQyBhbmQgd2FpdGluZyBm b3IgY2hhaXIgcHVibGljYXRpb24gcmVxdWVzdC4gVGhlIHByaW1hcnkgdGhpbmcNCm91dHN0YW5k aW5nIGlzIGEgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBSb3V0aW5nIEFEcyBhbmQgV0cgYXMgdG8g d2hldGhlcg0KaXQgd2lsbCBiZSBleHBlcmltZW50YWwgc3RhdHVzIG9yIFBTLiBJZiB5b3UgaGF2 ZSBjb25jZXJucywgYm90aCBkcmFmdHMNCmFyZSBzdWZmaWNpZW50bHkgY29tcGxldGUgdGhhdCB5 b3UgY291bGQgcmV2aWV3IGJvdGggbm93LCBidXQgSSBkb24ndA0KZXhwZWN0IG1ham9yIGNoYW5j ZXMgb2YgdGhlIHR5cGUgeW91IGV4cHJlc3MgY29uY2VybiBhYm91dCBhdCB0aGlzIGxhdGUNCnN0 YWdlLg0KQXMgcHJpbWFyeSBhdXRob3IsIEkgY2FuIHNheSB0aGF0IEknZCByZWFsbHkgbGlrZSB0 aGlzIHRvIGJlIG9mZiBteSBwbGF0ZQ0KYW5kIGluIHRoZSBSRkMgZWRpdG9yJ3MgcXVldWUsIGJl Y2F1c2UgZ2l2ZW4gY3VycmVudCBqb2IvbWVyZ2VyDQp1bmNlcnRhaW50eSwgSSBjYW4ndCBiZSBj ZXJ0YWluIHdoYXQgbXkgaW52b2x2ZW1lbnQgd2l0aCBJRVRGIHdpbGwgYmUgaW4NCnRoZSBjb21p bmcgbW9udGhzLiBDb21wbGV0aW5nIGFwcHJvdmFsIG9uIHRoaXMgb25lIHdoaWxlIGl0J3MgaW4g cXVldWUNCmFsc28gc2VlbXMgYSBiZXR0ZXIgdXNlIG9mIElFU0cgY3ljbGVzIHJhdGhlciB0aGFu IHJlLWN5Y2xpbmcgdGhlIGRyYWZ0DQpzdWNoIHRoYXQgaXQgaGFzIHRvIGJlIHJldmlld2VkIGFu ZCBkaXNjdXNzZWQgYnkgSUVTRyBhIHNlY29uZCB0aW1lLCBidXQgSQ0KZGVmZXIgdG8gdGhlIFdH IGFuZCBJRVNHIGFzIHRvIGhvdyB0byBwcm9jZWVkIGhlcmUuDQoNClRoYW5rcywNCg0KV2VzIEdl b3JnZQ0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29t cGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0t LS0tLS0NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgRS1t YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh YmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl bnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBD YWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg b3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNo bWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Tue May 3 07:37:17 2016 Return-Path: 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 3990812D845; Tue, 3 May 2016 07:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 tDZTW5CFKEwe; Tue, 3 May 2016 07:37:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3044E12D841; Tue, 3 May 2016 07:36:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 98C77BE73; Tue, 3 May 2016 15:36:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyn3tuogKCeP; Tue, 3 May 2016 15:36:55 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7FEB2BE54; Tue, 3 May 2016 15:36:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462286215; bh=Zb21Y+5zjc7B9IOZ6Vxg/dQzp/kYtrw/H3UfZT+7hbU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=wi7+eQXP6G0l9SpK3dVcMPBgNRvzCtYUF9tDmkbEdma/jMYmJA84HNHZkBx3OHeuv h4K5W0EQpGbmWMlJgxtOlHlQ8aABqxrtbIJndjPhVKioG8MPNtzOsee8Olss+l0xQH pf9WVI4uVI5fqdHALNK88QWRP6C8+zaAVcuueaKY= To: "George, Wes" , Kathleen Moriarty , The IESG References: <20160502170417.15717.29113.idtracker@ietfa.amsl.com> <57287DE3.9000604@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5728B785.3090100@cs.tcd.ie> Date: Tue, 3 May 2016 15:36:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010605030809000903060208" Archived-At: Cc: "morrowc@ops-netman.net" , "draft-ietf-sidr-as-migration@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:37:11 -0000 This is a cryptographically signed message in MIME format. --------------ms010605030809000903060208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 03/05/16 15:02, George, Wes wrote: > Completing approval on this one while it's in queue > also seems a better use of IESG cycles It's a minor point but evaluating this one really calls for having reviewed bgpsec as well so I think doing this one 1st will be a slightly less good use of IESG cycles. But, like I said, that's a minor point (assuming that bgpsec is in a good enough state - if it's not then I don't see how the IESG could approve this). S. --------------ms010605030809000903060208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDMx NDM2NTNaMC8GCSqGSIb3DQEJBDEiBCAi5KoaCWXztF1MxZpUSVKtz7QmaQfSpayQp/GSg2KF 7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCaoBagHZA/XOqrh0HaJ8Cl3uQHoMrA+F+DANA9bN6EuRdWRHZV6iON 7pGqay9wP++hOO/dR0r7wYlnpYZd+6xljJE0zE96r3GeiNt3qEdQP2m4M/LWuOARKGWgWBn+ Lhqd8fky2rrJ6pteaRTTCn/xedlCuzGYkj0Y4NtzseTvGPN0oD0+rgKoHypmhJQ8gIx77o91 aO5fk4IGRIfoO4PzykJPFpDPCwUcAoB+jfWCzQ7jA7hv2xOSsPCW9Xf5VfAwqcrb2JE9rmUt nzem40+ouFtTMdFg/HDprCv05R3Skp4mLqq1v9olRwR9Bp9rCgJqGWF6Am+nALUgWArUWxco AAAAAAAA --------------ms010605030809000903060208-- From nobody Tue May 3 10:32:13 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6EB12DCE9; Tue, 3 May 2016 10:32:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503173211.8288.89006.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 10:32:11 -0700 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:32:12 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sidr-as-migration-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm wondering a few things that I think are important to discuss. If this is all fine, I may have more comments as I think I'll need to dig into the BGPsec draft first and then this one again. 1. Why is this document preceding the BGP spec? Shouldn't this be part of the BGPSec protocol document? If BGPSec isn't getting deployed because of the AS path migration problem and this gets us a little further, but not quite as secure, maybe that's a trade off we need to accept. But this document coming through first is a little concerning even though the protocol spec is a normative reference. 2. The introduction makes this sound rather innocuous, but the security considerations section is more explicit that this is a work around BGPSec and isn't quite as secure. I'd like to see some text explaining this better in the introduction, more similar to what's in the first paragraph of the security considerations section. See comments below too with some text. Sandy said she was working on this section as well, thanks for that! Thank you ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think the Abstract & introduction are too brief. A lot of concerns might have been avoided with a little more explanation up front. --- Standards Track *is* right for this document, but it takes a little to understand that while the document doesn't make any changes to the protocol, it does describe how implementations use the protocol to deliver a specific function. --- Some rewording of the introduction could go a long way in helping with document clarity: Possibly: "This document describes how ASN migration may be performed securely using the RPKI and BGPSec mechanisms. It defines the implementation behavior during ASN migration, but does not define any changes to the BGPSec protocol." *Note - if the last part remains true --- 1.2 refers to "private ASNs" and this term is well understood. But the referenced RFC 1930 doesn't use that term. It uses the term "Reserved AS Numbers" and describes them as "reserved for private use". --- Section 2 has "...merging two or more ASNs..." I think it is ASes that are being merged. Ditto "...is not enabled between the ASNs..." --- Section 3 has Since they are using methods to migrate that do not require coordination with customers, they do not have a great deal of control over the length of the transition period as they might with something completely under their administrative control I can't parse this. If the methods do NOT require coordination with customers, surely the methods are wholly under the control of the operator. Is there a typo: s/do not require/require/ ? Or is there some other message? --- Section 3 As solutions were being proposed for RPKI implementations to solve this transition case, operational complexity and hardware scaling considerations associated with maintaining multiple legacy ASN keys on routers throughout the combined network have been carefully considered. As worded (passive voice) it demands a citation. Possibly it is meant to say that operators have carefully considered this. Maybe that the SIDR WG has done the consideration. --- Section 3 It would be helpful to add a final sentence saying what this section goes on to do. I think it examines the basic functions of RPKI to determine whether they already handle ASN migration and to identify any issues that might arise when an ASN changes. --- 3.1 Route Origin Validation as defined by RFC 6480 [RFC6480] does not need a unique solution to enable AS migration, as the existing protocol and procedure allows for a solution. That doesn't read too well to me at least, do you mean something like: Route Origin Validation as defined by RFC 6480 [RFC6480] does not need modification to enable AS migration, as the existing protocol and procedure allows for a solution as follows. --- 3.1 In the scenario discussed, AS64510 is being replaced by AS64500. s/discussed/discussed in RFC 7705/ --- There are some abbreviations that will need to be expanded (e.g., ROA) --- 3.2.1 has... However, there is currently no guidance in the BGPSec protocol specification [I-D.ietf-sidr-bgpsec-protocol] on whether or not the forward-signed ASN value is required to match the configured remote AS to validate properly "currently" looks unlikely to change at this stage given the status of draft-ietf-sidr-bgpsec-protocol. So, either - make the changes to draft-ietf-sidr-bgpsec-protocol while you can or - change this text to reflect reality as... "However, there is no guidance..." --- 3.2.1 s/remote as 64510/remote AS 64510/ s/local as 64510/local AS 64510/ --- 3.2.1 It took me several attempts to parse... Assuming that this mismatch will be allowed by vendor implementations and using it as a means to solve this migration case is likely to be problematic. Did you mean: If we assume that this mismatch will be allowed by vendor implementations and that using it as a means to solve this migration case, then we are likely to see problems when implementations disallow the mismatch. --- 3.2.2 However, if the updates are left intact, this will cause the AS Path length to be increased, which is undesirable as discussed in RFC7705 [RFC7705]. On reading this I thought: "Undesirable is OK for a short transition period," but I went and read 7705. There, in the introduction, it says "it is critical that the ISP does not increase AS_PATH length during or after ASN migration". So I would s/is undesirable/must be avoided/ (Note: Section 4 has this as MUST NOT.) --- The text before the bullets in section 4 should... s/listed in no particular order:/listed in no particular order. BGPSec:/ Then "BGPSec" can be deleted from the first bullet. --- In section 5... Since that PE has been moved to AS64500, it is not possible for it to forward-sign AS64510 with pCount=0 without some minor changes to the BGPSec implementation to address this use case. I know what this is saying, but it is a bit skewed since implementations are not normally in scope for our specs. Perhaps... Since that PE has been moved to AS64500, this described a new behavior for implementations to forward-sign AS64510 with pCount=0. --- Section 5 This document proposes applying a similar technique Too late! If this is to be an RFC on the Standards Track then This document describes how to apply a similar technique --- Section 5 has (see section 4.4 of the above-referenced draft) Really? Too tired to actually include the reference? But by the time this document is published the reference will be an RFC and this text will be left dangling. ---- 5.2 The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration implementation only. s/implementation/scenario/ --- I always love it when the Acknowledgements section thanks one of the authors :-) --- Section 8 This has happened before, but it usually leads the IESG to say "Hang on, why don't you just fix the protocol spec?" At the least, the Abstract and Introduction need to include the right text that would be present for an "Update". That is: what document is updated and what change is made. --- Section 9 Is "reasonably secure" should be replaced with something more accurate. Maybe this will come with the new text Sandy is working on. this is not fundamentally altering the existing security risks for BGPSec. That seems to say "...is somewhat (or marginally) altering..." which doesn't sound good. --- I hope the more detailed review is helpful. I still need to look at BGPsec to feel more comfortable with this one. From nobody Tue May 3 13:35:44 2016 Return-Path: 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 5E5E912D4FF; Tue, 3 May 2016 13:35:43 -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 ZiiWRUAmSux8; Tue, 3 May 2016 13:35:40 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 721E712D181; Tue, 3 May 2016 13:35:39 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id j74so39086588ywg.1; Tue, 03 May 2016 13:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=MJI4vVaZoN92l+62qvCShkmqqC66DyNoKKzb8iBljTI=; b=i4kLcEv4nTiqsoKe6gtVgeEkNDuMXHbote2yw58dPvCq3X0nqmq6cPH350UdiOpHjD oNHLL5tMQwtib/ClfSsT5B8vOU9pyKXyTJaPsnJyQJh/+GMGRTndWniTL4efmXux0Img BNcQjXCNkKUXO9a09A6nKDGKKoFKtG+m29eycihNIPn7jqxCTc0CXJPMeCn7QaltGiVS yw5tNaRBWJYbqB22o6wol4ot8MPHacUV+P3tadpArvZpd/JmCnyMdl90e3psMqKPB+DL 2XBbW91YyzjZDjFqai82Hif4N3kTJFd2RE59UbEzzV5YiolpGfF2yPCHQOv5+ftGasWn Zckg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MJI4vVaZoN92l+62qvCShkmqqC66DyNoKKzb8iBljTI=; b=fKBZTseUoYPyRlNce2bh7FA4TqkdX5dtr/a3WbFSU+RPoJufzRy3QUi86WT5K+0ZgP wHUM26QvwypYz1KTGzrai0z8DR3UZ4HnaejMZlLIu1jrGPU4qlASl9D7zuyhEZbzZLq9 bUy69doT7zbMMIxQARQKmhMwgEkvLttxVXl/eVg0UM8xbXM1JKqzIxyvxuMG+vO+ew/3 9goVM/xGJXVQKAYYKjbCu0zeY89w6CJhwLiEEIlInt9vWWtD3nIIBsas403mdbuhuNFW dJbcSbcrCGjVh40Xb1yWu3D93TbkTsjPP3NPVXiTHyZhzrOj2YCjGTLUSFdw1Fo2FV0L j5aA== X-Gm-Message-State: AOPr4FVwM1h56c+RTv2ZPN0xsFXGmc6SKsrK7QiOUSuNJjChKCeaN1kfHr+8QCHRDh/W0mpUAOlhH/Jv6Lx2SQ== MIME-Version: 1.0 X-Received: by 10.37.2.86 with SMTP id 83mr2414267ybc.159.1462307738689; Tue, 03 May 2016 13:35:38 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Tue, 3 May 2016 13:35:38 -0700 (PDT) In-Reply-To: References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net> Date: Tue, 3 May 2016 16:35:38 -0400 X-Google-Sender-Auth: dEiPg7kPdn-BdRN4XnaAE8bL6KM Message-ID: From: Christopher Morrow To: sidr Content-Type: multipart/alternative; boundary=001a113d3f6c51297c0531f60dd0 Archived-At: Cc: "sidr-chairs@ietf.org" , "sidr-ads@tools.ietf.org" Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:35:43 -0000 --001a113d3f6c51297c0531f60dd0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B howdy, it's past 4/29/2016 || 29/4/2016 || Mar 29 2016... and from the discussion on-list and mostly in the room in EZE, it appears: "Please maintain Proposed Standard as the track for SIDR work." i think this closes out the discussion. thanks for deliberating and discussing this topic! -chris co-chair On Mon, Apr 25, 2016 at 10:53 AM, Warren Kumari wrote: > ... and another +1. > W > > > On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels wrote: > >> >> > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) >> wrote: >> > >> > +1 with Standard Track. >> >> +1 >> >> > >> > The question could have been relevant six years ago and we may not hav= e >> > debated it that much then. Today, we are clearly beyond experimental >> draft >> > definition and we do not want to stop people working on the topic. >> > >> > Roque >> > >> > >> > >> > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" < >> sidr-bounces@ietf.org >> > on behalf of gih@apnic.net> wrote: >> > >> >> >> >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: >> >>> >> >>> I didn't attend the IETF meeting, but I did listen to the Wednesday >> >>> SIDR session, at >> >>> which the issue was raised as to whether the BGPSec RFC should be >> >>> standards track >> >>> or experimental. >> >>> >> >> >> >> I was in the room, but did not speak to this topic. >> >> >> >>> I believe standards track is the right approach here. >> >> >> >> I consulted the oracle of RFC2026 and read the following: >> >> >> >> A Proposed Standard specification is generally stable, has resolved >> >> known design choices, is believed to be well-understood, has receive= d >> >> significant community review, and appears to enjoy enough community >> >> interest to be considered valuable. However, further experience >> >> might result in a change or even retraction of the specification >> >> before it advances. >> >> >> >> This seems to fit well, including the caveats at the end. >> >> >> >> On the other hand: >> >> >> >> The "Experimental" designation typically denotes a specification that >> >> is part of some research or development effort. Such a specificatio= n >> >> is published for the general information of the Internet technical >> >> community and as an archival record of the work, subject only to >> >> editorial considerations and to verification that there has been >> >> adequate coordination with the standards process (see below). >> >> >> >> Which seems to fall short. >> >> >> >> The exercise of RFC publication of BGPSec is more than archival, and >> the >> >> process >> >> has been much more than a cursory exercise of coordination with the >> SIDR >> >> WG. While >> >> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2=B9= s >> >> Internet, that >> >> future uncertainty applies to most of the IETF=C2=B9s work, and that >> >> consideration >> >> should not preclude its publication as a Proposed Standard, as I >> >> interpret RFC2026. >> >> >> >> Geoff >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > --001a113d3f6c51297c0531f60dd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2= =80=8B
howd= y, it's past 4/29/2016 || 29/4/2016 || Mar 29 2016... and from the disc= ussion on-list and mostly in the room in EZE, it appears:

=C2=A0 "Please main= tain Proposed Standard as the track for SIDR work."

i think this closes out the discussion.

thanks for deliberating and = discussing this topic!

-c= hris
co-chair

On Mon, Apr 2= 5, 2016 at 10:53 AM, Warren Kumari <warren@kumari.net> wrote= :
... and another=C2=A0+= 1.
W
<= div class=3D"h5">

On Wed= , Apr 20, 2016 at 4:07 AM Tim Bruijnzeels <tim@ripe.net> wrote:

> On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:=
>
> +1 with Standard Track.

+1

>
> The question could have been relevant six years ago and we may not hav= e
> debated it that much then. Today, we are clearly beyond experimental d= raft
> definition and we do not want to stop people working on the topic.
>
> Roque
>
>
>
> On 14/04/16 22:20, "sidr on behalf of Geoff Huston" <sidr-bounces@ietf.or= g
> on behalf of gih@ap= nic.net> wrote:
>
>>
>>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <kent@bbn.com> wrote:
>>>
>>> I didn't attend the IETF meeting, but I did listen to the = Wednesday
>>> SIDR session, at
>>> which the issue was raised as to whether the BGPSec RFC should= be
>>> standards track
>>> or experimental.
>>>
>>
>> I was in the room, but did not speak to this topic.
>>
>>> I believe standards track is the right approach here.
>>
>> I consulted the oracle of RFC2026 and read the following:
>>
>>=C2=A0 A Proposed Standard specification is generally stable, has r= esolved
>>=C2=A0 known design choices, is believed to be well-understood, has= received
>>=C2=A0 significant community review, and appears to enjoy enough co= mmunity
>>=C2=A0 interest to be considered valuable.=C2=A0 However, further e= xperience
>>=C2=A0 might result in a change or even retraction of the specifica= tion
>>=C2=A0 before it advances.
>>
>> This seems to fit well, including the caveats at the end.
>>
>> On the other hand:
>>
>> The "Experimental" designation typically denotes a speci= fication that
>>=C2=A0 is part of some research or development effort.=C2=A0 Such a= specification
>>=C2=A0 is published for the general information of the Internet tec= hnical
>>=C2=A0 community and as an archival record of the work, subject onl= y to
>>=C2=A0 editorial considerations and to verification that there has = been
>>=C2=A0 adequate coordination with the standards process (see below)= .
>>
>> Which seems to fall short.
>>
>> The exercise of RFC publication of BGPSec is more than archival, a= nd the
>> process
>> has been much more than a cursory exercise of coordination with th= e SIDR
>> WG. While
>> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2= =B9s
>> Internet, that
>> future uncertainty applies to most of the IETF=C2=B9s work, and th= at
>> consideration
>> should not preclude its publication as a Proposed Standard, as I >> interpret RFC2026.
>>
>> Geoff
>>
>>
>> _______________________________________________
>> 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

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


--001a113d3f6c51297c0531f60dd0-- From nobody Tue May 3 13:39:48 2016 Return-Path: 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 619BA12D896 for ; Tue, 3 May 2016 13:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 ARa8Y59dgKeL for ; Tue, 3 May 2016 13:39:44 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 AC29E12D899 for ; Tue, 3 May 2016 13:39:39 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id a17so60064462wme.0 for ; Tue, 03 May 2016 13:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=J0onmw0aV5aPTxMRcz/PTXoZaAVE4vQdQPH+tJXxMZA=; b=XOJMR4d1Imw2xewY/Cfy9eBJU6MS3OOIGmIwf03Lk4ArjoqegqMbZdu8NsVspzipf/ ML6TQxRZs9xKzl4+SrFlCdKRlNQo3SpIdz/2JqpWS+6R6oqj037GI5o8A10DT68S3P50 +W8piiarOSxryEk6ZoMdzWLvoVI4P7OnmD3VhR3B29yuNXvJIZ2GuY7zQty06/Uxg0BB FYNbh6pLYypCj6YrTZVui6bvDbmqw/gSO/2DEbibmtJPuczga1MDK0tveXMkXxCJ6TMs 9BWMXqcNiHlvEgFaCmUVnJdPXS3X02iZMIYXcHWvHBO5wkJhkD8u0FAiGJyJt/jso1jn vjjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=J0onmw0aV5aPTxMRcz/PTXoZaAVE4vQdQPH+tJXxMZA=; b=E7keW2qk06HO30OBl93N8TxwxGNN7MUAIkD8MkIPUWK4AJnOv6UBVaBDSJuJ75DfXu 3qJ+M3AJUiiEXzDMtXiEEuPvIZnuJKGJhxP8ZeK9/GdY2CbC1RRho8xMWf4FJN5AsMh7 UIwo6ab7K23cvKw45aWCfC7tvzohkMWIY6fCWFc+ucnaUZfyQgAJb/XOM+VvvYChapW6 +JxkERQUSvK02mE+VhfLv0YgzmFjYlTEInkjDKOI4B66Q4mHfcoSIlU8Jsn24fW1F4pg ApRrNEg4OTPI8UpgFNK2FrMJcG1ZxQYl8YN78X/8R4TsWR3LarYeyv7I7KlLNLiip4Fx e1wQ== X-Gm-Message-State: AOPr4FVNYJ0GqKTByZCMM+v2dhur2+Nxk5yMEHciMoeE6cq8K5yuDJVzmLxx9zjo/cZFt6EMhzT8f0eCJXVfkQ== X-Received: by 10.194.5.101 with SMTP id r5mr4991785wjr.47.1462307978068; Tue, 03 May 2016 13:39:38 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.194.64.134 with HTTP; Tue, 3 May 2016 13:38:58 -0700 (PDT) In-Reply-To: References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> From: Sharon Goldberg Date: Tue, 3 May 2016 16:38:58 -0400 X-Google-Sender-Auth: 1B-jCQF7PnxFr-dLOYbN-xfOMSA Message-ID: To: "Roque Gagliano (rogaglia)" Content-Type: multipart/alternative; boundary=047d7b5d3e5c95cace0531f61be7 Archived-At: Cc: sidr Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:39:47 -0000 --047d7b5d3e5c95cace0531f61be7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to Roque's point. Definitely standards track. Thanks, Sharon On Tue, Apr 19, 2016 at 6:31 PM, Roque Gagliano (rogaglia) < rogaglia@cisco.com> wrote: > +1 with Standard Track. > > The question could have been relevant six years ago and we may not have > debated it that much then. Today, we are clearly beyond experimental draf= t > definition and we do not want to stop people working on the topic. > > Roque > > > > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" on behalf of gih@apnic.net> wrote: > > > > >> On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: > >> > >> I didn't attend the IETF meeting, but I did listen to the Wednesday > >>SIDR session, at > >> which the issue was raised as to whether the BGPSec RFC should be > >>standards track > >> or experimental. > >> > > > >I was in the room, but did not speak to this topic. > > > >> I believe standards track is the right approach here. > > > >I consulted the oracle of RFC2026 and read the following: > > > > A Proposed Standard specification is generally stable, has resolved > > known design choices, is believed to be well-understood, has received > > significant community review, and appears to enjoy enough community > > interest to be considered valuable. However, further experience > > might result in a change or even retraction of the specification > > before it advances. > > > >This seems to fit well, including the caveats at the end. > > > >On the other hand: > > > > The "Experimental" designation typically denotes a specification that > > is part of some research or development effort. Such a specification > > is published for the general information of the Internet technical > > community and as an archival record of the work, subject only to > > editorial considerations and to verification that there has been > > adequate coordination with the standards process (see below). > > > >Which seems to fall short. > > > >The exercise of RFC publication of BGPSec is more than archival, and the > >process > >has been much more than a cursory exercise of coordination with the SIDR > >WG. While > >BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2=B9s > >Internet, that > >future uncertainty applies to most of the IETF=C2=B9s work, and that > >consideration > >should not preclude its publication as a Proposed Standard, as I > >interpret RFC2026. > > > >Geoff > > > > > >_______________________________________________ > >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 > > --=20 Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --047d7b5d3e5c95cace0531f61be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Roque's point.=C2=A0 Definitely standards track.=

Thanks,
Sharon

On Tue, Apr 19, 2016 at 6:31 PM, Roq= ue Gagliano (rogaglia) <rogaglia@cisco.com> wrote:
+1 with Standard Track.

The question could have been relevant six years ago and we may not have
debated it that much then. Today, we are clearly beyond experimental draft<= br> definition and we do not want to stop people working on the topic.

Roque



On 14/04/16 22:20, "sidr on behalf of Geoff Huston" <sidr-bounces@ietf.org
on behalf of gih@apnic.net> wrote:

>
>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <kent@bbn.com> wrote:
>>
>> I didn't attend the IETF meeting, but I did listen to the Wedn= esday
>>SIDR session, at
>> which the issue was raised as to whether the BGPSec RFC should be<= br> >>standards track
>> or experimental.
>>
>
>I was in the room, but did not speak to this topic.
>
>> I believe standards track is the right approach here.
>
>I consulted the oracle of RFC2026 and read the following:
>
>=C2=A0 =C2=A0A Proposed Standard specification is generally stable, has= resolved
>=C2=A0 =C2=A0known design choices, is believed to be well-understood, h= as received
>=C2=A0 =C2=A0significant community review, and appears to enjoy enough = community
>=C2=A0 =C2=A0interest to be considered valuable.=C2=A0 However, further= experience
>=C2=A0 =C2=A0might result in a change or even retraction of the specifi= cation
>=C2=A0 =C2=A0before it advances.
>
>This seems to fit well, including the caveats at the end.
>
>On the other hand:
>
>=C2=A0 The "Experimental" designation typically denotes a spe= cification that
>=C2=A0 =C2=A0is part of some research or development effort.=C2=A0 Such= a specification
>=C2=A0 =C2=A0is published for the general information of the Internet t= echnical
>=C2=A0 =C2=A0community and as an archival record of the work, subject o= nly to
>=C2=A0 =C2=A0editorial considerations and to verification that there ha= s been
>=C2=A0 =C2=A0adequate coordination with the standards process (see belo= w).
>
>Which seems to fall short.
>
>The exercise of RFC publication of BGPSec is more than archival, and th= e
>process
>has been much more than a cursory exercise of coordination with the SID= R
>WG. While
>BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2=B9s<= br> >Internet, that
>future uncertainty applies to most of the IETF=C2=B9s work, and that >consideration
>should not preclude its publication as a Proposed Standard, as I
>interpret RFC2026.
>
>Geoff
>
>
>_______________________________________________
>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




--
=
Sharon Goldberg
Computer Science, Boston = University
ht= tp://www.cs.bu.edu/~goldbe
--047d7b5d3e5c95cace0531f61be7-- From nobody Tue May 3 13:43:57 2016 Return-Path: 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 37BE412D627 for ; Tue, 3 May 2016 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 t8YIC3oh2T8A for ; Tue, 3 May 2016 13:43:52 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0107.outbound.protection.outlook.com [23.103.200.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B6D12D89F for ; Tue, 3 May 2016 13:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tVyKhWqkqYKt2xLQjnAgTPk8McQiWOYPj9thlP9HygU=; b=SR9ISZ0S3e45qJPaDQuGf9zSmH9iXDo+tX0HUggjpfrOunCAmRupvdqXc0483fcx03aHW/0fpCDzS7DVweteK9TwZCVryss7q5dsDiASEtaSrcgEaUvxKJFr00l+TjvYQ0p8dy246shOctY7I+CE3GGGfXHVKFAJjrIkV1g9H4w= Received: from SN1PR09MB0974.namprd09.prod.outlook.com (10.169.127.154) by SN1PR09MB0974.namprd09.prod.outlook.com (10.169.127.154) with Microsoft SMTP Server (TLS) id 15.1.485.9; Tue, 3 May 2016 20:43:47 +0000 Received: from SN1PR09MB0974.namprd09.prod.outlook.com ([10.169.127.154]) by SN1PR09MB0974.namprd09.prod.outlook.com ([10.169.127.154]) with mapi id 15.01.0485.011; Tue, 3 May 2016 20:43:47 +0000 From: "Borchert, Oliver (Fed)" To: Tim Bruijnzeels , "carlos@lacnic.net" Thread-Topic: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 Thread-Index: AQHRoH4CAEReRKcAT06+pOQJzVQOGZ+lrT6AgAFVpwCAAHIKAA== Date: Tue, 3 May 2016 20:43:47 +0000 Message-ID: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <572756FF.8030406@gmail.com> <9864FF77-D431-43F1-9077-E8A557053BC0@ripe.net> In-Reply-To: <9864FF77-D431-43F1-9077-E8A557053BC0@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ripe.net; dkim=none (message not signed) header.d=none;ripe.net; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-ms-office365-filtering-correlation-id: 7ee77ce3-dfd9-44a2-30f2-08d37393a062 x-microsoft-exchange-diagnostics: 1; SN1PR09MB0974; 5:cvVh814DgkWLMlGxzAC+fCVthojRXnN9tTQGhua/uvKbgJtLflydCoR1UZLtgxpQklKv80Wf85zpw3wTDaFdKCmSYTqB6+KL9fH+xLfA1omGscAFp/4t+k4TYTdKMYnyPZFDgR8KyjpBHFuFTfBQpQ==; 24:+7y1vdewseNRhuV91Q+OTW/tlI1tNpMs/Vj0R0VXJlwSE8Qegt0QREijl4p3UzH3rVumRzAZF8KrNtX2Ybz4NGdqUkExTiTVx1jlt8L5VDI=; 7:dpK9BuwsNmaItGTcjF3YUTM7L7/hERh1Qslly8Y+bu1RZiV9oAYKjLmd+YSKSSchabG5uKidboMN1ulXUjmAOiMV4TjPtV9pA2FwJLP6pIvooZWRcqEs5p3pOwjhtfy9scF3BpiAIGElv9m85GXoiarqtmiy9ndS+jwu7tTzF+bGi+m20JM4AKeB3O65cnce x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR09MB0974; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521096)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR09MB0974; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0974; x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(53754006)(15975445007)(87936001)(33656002)(8936002)(122556002)(66066001)(19580395003)(2950100001)(2900100001)(19580405001)(77096005)(10400500002)(36756003)(189998001)(2906002)(3660700001)(102836003)(86362001)(1220700001)(11100500001)(2501003)(3846002)(4001350100001)(5002640100001)(586003)(5008740100001)(230783001)(54356999)(76176999)(50986999)(99286002)(3280700002)(83716003)(92566002)(106116001)(81166005)(5004730100002)(82746002)(4326007)(83506001)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0974; H:SN1PR09MB0974.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7626293A322B7844A3F5EC135A816D82@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2016 20:43:47.5048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0974 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:43:55 -0000 SGksDQoNCkkgc3VwcG9ydCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLA0KDQpPbGl2ZXINCg0KDQoN Cg0KT24gNS8zLzE2LCA1OjU1IEFNLCAic2lkciBvbiBiZWhhbGYgb2YgVGltIEJydWlqbnplZWxz IiA8c2lkci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0aW1AcmlwZS5uZXQ+IHdyb3Rl Og0KDQo+SGksDQo+DQo+SSBiZWxpZXZlIHRoaXMgaXMgdXNlZnVsIHdvcmsgYW5kIHN1cHBvcnQg YWRvcHRpb24uIEhhcHB5IHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRpc2N1c3Npb24gd2hlcmUgSSBj YW4uDQo+DQo+VGltDQo+DQo+DQo+DQo+DQo+PiBPbiAwMiBNYXkgMjAxNiwgYXQgMTU6MzIsIENh cmxvcyBNLiBNYXJ0aW5leiA8Y2FybG9zbTMwMTFAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4g SGVsbG8gYWxsLA0KPj4gDQo+PiBMQUNOSUMgaGFzIHdvcmtlZCBvbiB0aHJlZSBwcm9qZWN0cyBp bnZvbHZpbmcgUlBLSS1lbmFibGluZyBJWFBzIFswXS4gV2UNCj4+IGNlcnRhaW5seSBzdXBwb3J0 IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBpdGVtIGFuZCB3aWxsDQo+PiBwYXJ0 aWNpcGF0ZSBpbiB0aGUgZGlzY3Vzc2lvbi4NCj4+IA0KPj4gVGhhbmtzIQ0KPj4gDQo+PiAtQ2Fy bG9zDQo+PiANCj4+IFswXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZm1lamlh LW9wc2VjLW9yaWdpbi1hLWNvdW50cnktMDINCj4+IA0KPj4gT24gNC8yNy8xNiA4OjExIEFNLCBT YW5kcmEgTXVycGh5IHdyb3RlOg0KPj4+IFRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIHdvcmtp bmcgZ3JvdXAgYWRvcHRpb24gZm9yIGRyYWZ0LWtrbGYtc2lkci1yb3V0ZS1zZXJ2ZXItcnBraS1s aWdodC0wMSwgIlNpZ25hbGluZyBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gUmVzdWx0cyBmcm9t IGEgUm91dGUtU2VydmVyIHRvIFBlZXJz4oCdLg0KPj4+IA0KPj4+IFRoaXMgbWVzc2FnZSBzdGFy dHMgYW4gYWRvcHRpb24gY2FsbCB0aGF0IHdpbGwgZW5kIGluIHR3byB3ZWVrcyBvbiAxMSBNYXkg MjAxNi4NCj4+PiANCj4+PiBQbGVhc2UgcmVzcG9uZCBvbiB0aGUgbGlzdCB0byBzYXkgd2hldGhl ciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIHdvcmsgYXMgYSB3b3JraW5nIGdyb3VwIHdv cmsgaXRlbSBBTkQgd2hldGhlciB5b3Ugd2lsbCBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGlzY3Vzc2lv bi4NCj4+PiANCj4+PiBSZW1lbWJlciB0aGF0IHdvcmtpbmcgZ3JvdXAgY29uc2Vuc3VzIHRvIGFk b3B0IHRoZSB3b3JrIG5lZWRzIHJlc3BvbnNlcywgbm90IGp1c3QgYWJzZW5jZSBvZiBvYmplY3Rp b24sIHNvIHNwZWFrIHVwLg0KPj4+IA0KPj4+IFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtrbGYtc2lkci1yb3V0ZS1zZXJ2ZXItcnBr aS1saWdodC0wMQ0KPj4+IA0KPj4+IOKAlFNhbmR5LCBzcGVha2luZyBhcyBvbmUgb2YgdGhlIHdn IGNvLWNoYWlycw0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2lkciBtYWlsaW5nIGxpc3QNCj4+ PiBzaWRyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaWRyDQo+Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBzaWRyIG1haWxpbmcgbGlzdA0KPj4gc2lkckBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaWRyIG1haWxpbmcgbGlz dA0KPnNpZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpZHINCg== From nobody Tue May 3 16:47:16 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E12A12DB5B; Tue, 3 May 2016 16:47:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503234713.8264.10628.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 16:47:13 -0700 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-as-migration-05: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 23:47:13 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-as-migration-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Kathleen (and others) in terms of timing on seeing this particular document. What is the time-line for seeing BGPSec at the IESG now that the in-WG discussion regarding its status has concluded? From nobody Tue May 3 23:56:16 2016 Return-Path: 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 1804E12D5A2 for ; Tue, 3 May 2016 23:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.595 X-Spam-Level: X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dPM3Zl0TrSwS for ; Tue, 3 May 2016 23:55:45 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9EA12D59E for ; Tue, 3 May 2016 23:55:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,575,1454972400"; d="scan'208";a="2848906" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw011.de-cix.net with ESMTP; 04 May 2016 08:55:00 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id B5CD5B009D; Wed, 4 May 2016 08:55:00 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 4 May 2016 08:55:00 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1156.000; Wed, 4 May 2016 08:55:00 +0200 From: Thomas King To: "sidr@ietf.org" Thread-Topic: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt Thread-Index: AQHRn52SzdB4iNpq/Ee01GU1Y2aqTp+b/c8AgAAyxYCADCwwgA== Date: Wed, 4 May 2016 06:55:00 +0000 Message-ID: <8C3143DE-F7F4-4AC1-88EC-3B6E77D762A1@de-cix.net> References: <5B8B8060-A9ED-427D-85BD-50723DA4CBB9@de-cix.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.60.10] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "John G. Scudder" , "Sriram, Kotikalapudi \(Fed\)" , Matthias Waehlisch Subject: Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 06:56:14 -0000 SSBwcm9wb3NlIHRvIGFkZCB0aGUgZm9sbG93aW5nIHRvIHNlY3Rpb24g4oCcT3BlcmF0aW9uYWwg UmVjb21tZW5kYXRpb25z4oCdOg0KDQozLjMuICBJbmZvcm1hdGlvbiBhYm91dCBWYWxpZGl0eSBv ZiBhIEJHUCBQcmVmaXggT3JpZ2luIE5vdCBBdmFpbGFibGUgYXQNCiAgICAgIGEgUm91dGUtU2Vy dmVyDQoNCiAgIEluIGNhc2UgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHZhbGlkaXR5IG9mIGEgQkdQ IHByZWZpeCBvcmlnaW4gaXMgbm90DQogICBhdmFpbGFibGUgYXQgdGhlIHJvdXRlLXNlcnZlciAo ZS5nLiwgZXJyb3IgaW4gdGhlIFJPQSBjYWNoZSwgQ1BVDQogICBvdmVybG9hZCkgdGhlIHJvdXRl LXNlcnZlciBNVVNUIE5PVCBhZGQgdGhlIEJHUCBQcmVmaXggT3JpZ2luDQogICBWYWxpZGF0aW9u IFN0YXRlIEV4dGVuZGVkIENvbW11bml0eSB0byB0aGUgcm91dGUuDQoNCg0KDQpCZXN0IHJlZ2Fy ZHMsDQpUaG9tYXMNCg0KDQoNCg0KT24gMjYvMDQvMjAxNiwgMTQ6MzMsICJUaG9tYXMgS2luZyIg PHRob21hcy5raW5nQGRlLWNpeC5uZXQ+IHdyb3RlOg0KDQo+SSB3b3VsZCBsaWtlIHRvIGNvbWUg YmFjayB0byBhIHNvbHV0aW9uIHRoYXQgd2FzIGRpc2N1c3NlZCBhbHJlYWR5OiBJZiB0aGUgcm91 dGUtc2VydmVyIGlzIG5vdCBhYmxlIHRvIHBlcmZvcm0gdGhlIG9yaWdpbiBwcmVmaXggdmFsaWRh dGlvbiB0aGUgQkdQIGNvbW11bml0eSBpcyBub3QgYWRkZWQgdG8gdGhlIEJHUCB1cGRhdGUuIFRo ZSBCR1AgY29tbXVuaXR5IGlzIG9ubHkgYWRkZWQgaWYgdGhlIG9yaWdpbiBwcmVmaXggdmFsaWRh dGlvbiBjb3VsZCBiZSBleGVjdXRlZC4NCj4NCj5UaGlzIHNvbHV0aW9uIGFsbG93cyBhIGNsZWFy IHNpZ25hbGxpbmcuIFRoaXMgd291bGQgYWxzbyBiZSBjb21wYXRpYmxlIHdpdGggdGhlIGN1cnJl bnQgaWV0Zi1zaWRyLW9yaWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZyBkb2N1bWVudCBhbmQgY291 bGQgYmUgZWFzaWx5IHN0YXRlZCBpbiBkcmFmdC1ra2xmLXNpZHItcm91dGUtc2VydmVyLXJwa2kt bGlnaHQuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlRob21hcw0KPg0KPg0KPg0KPg0KPk9uIDI2LzA0 LzIwMTYsIDEzOjMyLCAiTWF0dGhpYXMgV2FlaGxpc2NoIiA8bS53YWVobGlzY2hAZnUtYmVybGlu LmRlPiB3cm90ZToNCj4NCj4+VGhlcmUgd2FzIGEgcXVpdGUgc2ltaWxhciBkaXNjdXNzaW9uIGlu IDIwMTMsIGZvciB0aGUgdGhyZWFkIHNlZQ0KPj4NCj4+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9zaWRyL3p2U1BfLWlpRWZ1X2FjWUluSzVsT01ueXM1VQ0KPj4NCj4+QXMg ZmFyIGFzIEkgcmVtZW1iZXIgdy9vIGEgZmluYWwgY29uY2x1c2lvbiAob3IgdGhlIGNvbmNsdXNp b24gd2FzIA0KPj5sZWF2ZSBpdCBhcyBpcykuDQo+Pg0KPj4NCj4+Q2hlZXJzDQo+PiAgbWF0dGhp YXMNCj4+DQo+Pk9uIFR1ZSwgMjYgQXByIDIwMTYsIFRob21hcyBLaW5nIHdyb3RlOg0KPj4NCj4+ PiBIaSBhbGwsDQo+Pj4gDQo+Pj4gRm9sbG93aW5nIHVwIG9uIHRoZSBkaXNjdXNzaW9uIHdlIGhh ZCBkdXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5nIEkgd291bGQgbGlrZSB0byBkaXNjdXNzIHdp dGggeW91IGhvdyB3ZSBwcm9jZWVkIHdpdGggdGhlIOKAnERpZCBub3QgcGVyZm9ybSB2YWxpZGF0 aW9u4oCdIHZhbHVlLiBJIHRoaW5rIHRoaXMgdmFsdWUgaXMgdmVyeSBpbXBvcnRhbnQgYW5kIHNo b3VsZCBiZSBhZGRlZCB0byBpZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5nLg0K Pj4+IA0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBUaG9tYXMNCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHNpZHIgbWFpbGluZyBsaXN0DQo+ Pj4gc2lkckBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lkcg0KPj4+IA0KPj4NCj4+DQo+Pi0tIA0KPj5Eci4gTWF0dGhpYXMgV2FlaGxpc2NoDQo+ Pi4gIEZyZWllIFVuaXZlcnNpdGFldCBCZXJsaW4sIEluc3QuIGZ1ZXIgSW5mb3JtYXRpaywgQUcg Q1NUDQo+Pi4gIFRha3VzdHIuIDksIEQtMTQxOTUgQmVybGluLCBHZXJtYW55DQo+Pi4uIG1haWx0 bzptLndhZWhsaXNjaEBmdS1iZXJsaW4uZGUgLi4gaHR0cDovL3d3dy5pbmYuZnUtYmVybGluLmRl L353YWVobA0KPj46LiBBbHNvOiBodHRwOi8vaW5ldC5oYXctaGFtYnVyZy5kZSAuLiBodHRwOi8v d3d3LmxpbmstbGFiLm5ldA0K From nobody Wed May 4 00:57:34 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A75A012D0C6; Wed, 4 May 2016 00:57:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504075732.8350.8981.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 00:57:32 -0700 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Record on draft-ietf-sidr-as-migration-05: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 07:57:33 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-as-migration-05: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've yet to review this one, but I'd like to join the chorus asking that this be put onto the same telechat as bgpsec - based on a quick scan I can't see how I can evaluate this without also evaluating bgpsec. If this stays on this week's telechat I may not have time to review both (I do think bgpsec deserves a proper review), in which case I may have to hit the "defer" button tomorrow. (This note is just a heads up for that, in the hope that someone else pushes this out in the meantime:-) From nobody Thu May 5 03:54:08 2016 Return-Path: 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 D4B3F12D126 for ; Thu, 5 May 2016 03:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 Y5z7LYs68b4z for ; Thu, 5 May 2016 03:54:06 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 A65EA12D0F5 for ; Thu, 5 May 2016 03:54:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Sandra Murphy'" , "'sidr'" References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Date: Thu, 5 May 2016 06:54:11 -0400 Message-ID: <078d01d1a6bc$75188a20$5f499e60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQN7eanC9G/y+rRZofWNwu3s4j8m+JxWhWHA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 10:54:08 -0000 Support adoption. Will participate in discussion. Important to getting deployment (IMO). Sue Hares -----Original Message----- From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Sandra Murphy Sent: Wednesday, April 27, 2016 8:12 AM To: sidr Cc: Sandra Murphy Subject: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 The authors have requested working group adoption for draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin Validation Results from a Route-Server to Peers". This message starts an adoption call that will end in two weeks on 11 May 2016. Please respond on the list to say whether you support adoption of this work as a working group work item AND whether you will participate in the discussion. Remember that working group consensus to adopt the work needs responses, not just absence of objection, so speak up. The draft is available at https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 -Sandy, speaking as one of the wg co-chairs From nobody Thu May 5 08:51:59 2016 Return-Path: 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 6A8F312D6D5 for ; Thu, 5 May 2016 08:51:58 -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 FLOU2JPYQKBu for ; Thu, 5 May 2016 08:51:56 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 CFFEC12D6D2 for ; Thu, 5 May 2016 08:51:55 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id o66so144131713ywc.3 for ; Thu, 05 May 2016 08:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=IFEmS7NjAWbdsuZPRh9LNooPFk/qLmWjp1plumcwzto=; b=jDcNFlOX5feum28FK3AfLiSu/RYJUDj2/FbulPRIOoWlaZ0kVqNNTdt2D5Wc94lNUM 43XPcX9ONuQ54V2NBpnEpFn6WKHB45zsg6lEeZJVx6xiYQRJQ+hfgZZbLatb65B14OYG gD4+Ya5SAihBekX3+ZrZ9of7Tru7WbTC5eKDQn24KQHRwf/t7934lhTJs8RQaPTsLkKU 49OynBri9mNhmcN5nWSRKZpPa9FWZHSsuLDd3XcCXTMB1UmDxSVFzs5B79cJ2Nn7dvDe GatJGjDQ0Q/i/63DfbD3JHmuTVffxckB6NYDHUKGMUi+ZhlN3/DMuvkDixS8EHUSzZkR Paag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IFEmS7NjAWbdsuZPRh9LNooPFk/qLmWjp1plumcwzto=; b=SIIJ2AwCbeGpmN2E0Vjp7bMk+39HQtkKN7WOFyyC3osJ9FakGqdMHkXXVRbFZ/DpgB ZXr/+HEU/3B1sJpGQ20r9eJLQqA4eCyHovK/AP700cM/2VB9oh+D43PRQ0rJZ3LjJpRg q/sSvic/hrHlJeJpyQeiw/uzl6+sFyYhs6omf3Pw25H8QG4f560SCrwzGjalQ9Zj22dS nY/VGS42CJcXN7Scha8ar8UkIOagy8a4ulPH2ObKuE30I/uv6s/uFTMTXlVb+q2t1hBt 3ULowWdy4red5c20wF+lhaXsbeELIto7svq0VvYIxphid6eNEsNKR0LaCfAgr3fnR0hC eFgg== X-Gm-Message-State: AOPr4FXNtVws5KBDhYpcS3Z8FbFDzkVx1lVi9IMz92Q3cv/n5ln1aWGcKNiqHWfhAug91k8+OxF48pDnEUHbdQ== MIME-Version: 1.0 X-Received: by 10.37.56.147 with SMTP id f141mr3315722yba.159.1462463515050; Thu, 05 May 2016 08:51:55 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Thu, 5 May 2016 08:51:54 -0700 (PDT) In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Date: Thu, 5 May 2016 11:51:54 -0400 X-Google-Sender-Auth: rXQqaj5y72DgFrHpNCrfL1eNmfA Message-ID: From: Christopher Morrow To: Sandra Murphy Content-Type: multipart/alternative; boundary=94eb2c09d8564fd83305321a5278 Archived-At: Cc: sidr Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 15:51:58 -0000 --94eb2c09d8564fd83305321a5278 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (as a working group person) I think it's an interesting topic to discuss, I'm a little worried that: "Because the third party said things are 'ok' I'll believe things are ok!" mostly because I don't see a clear method to ensure that 'third party' has: 1) up-to-date information 2) my best interest at heart 3) current/appropriate configuration I suppose it's interesting to see another's view of the world, I don't necessarily want to believe it myself though. On Wed, Apr 27, 2016 at 8:11 AM, Sandra Murphy wrote: > The authors have requested working group adoption for > draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin > Validation Results from a Route-Server to Peers=E2=80=9D. > > This message starts an adoption call that will end in two weeks on 11 May > 2016. > > Please respond on the list to say whether you support adoption of this > work as a working group work item AND whether you will participate in the > discussion. > > Remember that working group consensus to adopt the work needs responses, > not just absence of objection, so speak up. > > The draft is available at > https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 > > =E2=80=94Sandy, speaking as one of the wg co-chairs > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > --94eb2c09d8564fd83305321a5278 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(as= a working group person)

= I think it's an interesting topic to discuss, I'm a little worried = that: "Because the third party said things are 'ok' I'll b= elieve things are ok!"

mostly because I don't see a clear method to ensure that 'third = party' has:
=C2=A0 1) up-to-date information
=C2=A0 2) my best interest at heart
=C2=A0 3) current= /appropriate configuration

I suppose it's interesting to see another's view of the world, I = don't necessarily want to believe it myself though.


On Wed, Apr 27, 2016 at 8:11 AM, Sa= ndra Murphy <sandy@tislabs.com> wrote:
The authors have requested working group adoption for draft-k= klf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin Validati= on Results from a Route-Server to Peers=E2=80=9D.

This message starts an adoption call that will end in two weeks on 11 May 2= 016.

Please respond on the list to say whether you support adoption of this work= as a working group work item AND whether you will participate in the discu= ssion.

Remember that working group consensus to adopt the work needs responses, no= t just absence of objection, so speak up.

The draft is available at http= s://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01

=E2=80=94Sandy, speaking as one of the wg co-chairs



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


--94eb2c09d8564fd83305321a5278-- From nobody Thu May 5 09:02:18 2016 Return-Path: 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 69AB212D6EA for ; Thu, 5 May 2016 09:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 Zb63M6PQjK1T for ; Thu, 5 May 2016 09:02:15 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 8AEF212D515 for ; Thu, 5 May 2016 09:02:15 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ayLjA-000ohP-I4>; Thu, 05 May 2016 18:02:12 +0200 Received: from x5ce7e3e9.dyn.telefonica.de ([92.231.227.233] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1ayLjA-003qp6-7c>; Thu, 05 May 2016 18:02:12 +0200 Date: Thu, 5 May 2016 18:01:53 +0200 From: Matthias Waehlisch To: Christopher Morrow In-Reply-To: Message-ID: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="253818414-31862-1462463891=:2308" Content-ID: X-Originating-IP: 92.231.227.233 Archived-At: Cc: sidr , Sandra Murphy Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 16:02:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --253818414-31862-1462463891=:2308 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: Hi Chris, I'm not sure if I get your point. On Thu, 5 May 2016, Christopher Morrow wrote: > I think it's an interesting topic to discuss, I'm a little worried > that: "Because the third party said things are 'ok' I'll believe > things are ok!" > > mostly because I don't see a clear method to ensure that 'third party' has: >   1) up-to-date information > Same with RTR cache server. >   2) my best interest at heart > If you peer with a route server, you should establish a trust relation anyway. >   3) current/appropriate configuration > Same with RTR cache erver. Cheers matthias -- Dr. Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:m.waehlisch@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net --253818414-31862-1462463891=:2308-- From nobody Thu May 5 12:30:59 2016 Return-Path: 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 D0E6912D80C for ; Thu, 5 May 2016 12:30: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 ctqRpXW1SynE for ; Thu, 5 May 2016 12:30:55 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 5971612D7D8 for ; Thu, 5 May 2016 12:30:55 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g133so139306845ywb.2 for ; Thu, 05 May 2016 12:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RTLGAf9lqpL6vU6dyoxqbNjOJQzH+4kNnAGRW+7CpI8=; b=OGEwiSPCoNopHOKrA3Wz0tmQcOIMROsSgtALEJw6SNNcC4rwpRzV9NbUk/Cntx5tSj T/vnq9BP70CUEM5yA0HGbrNmF2GMPdUpA1tSTkbAE6J1ZMS0hKnhc4620a047onAhv2O BZSJprwzVfN7NWWBygiZErE9dPnal3o9l+ywMkM3VwcX9bgxBL7j5RpccpWR+mhD5hMw E2n+H+n6BI/t37ENEArR5BGIVAXqpMLbtoeIkEy+4xZVOIvtyrf5SquEgt2bC2QaeLAj iwRRnsUI+AyZ588VN5J4sopAiVFtpRMvIJZupku+n1P10XdeDDDong8Xuw5ohHQPOU4P m/5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RTLGAf9lqpL6vU6dyoxqbNjOJQzH+4kNnAGRW+7CpI8=; b=Rt1YXx9AbxrZsZqW6v5/ipI3sMDp7af6TW1eVm5G6/Tyj5iGrxgAUncZd7FRHYHWK8 7js1BhhVGr4vEb+pWrSmUZdI6E+NNZrf1MuYJBlC8EXRUCbi2JxuWSGJhV+1U5atryAB SdW1uIMIIseETbd56E7oux3toOZsWmL+zBnlWZMFCjz5/NpqBa2Y0ERp7q+Cc+6Yrwth WmgvkklMKXZI+8P5JabwZLKoD0BYwgH5MIOzyjfV0u+HaoGC2Ez8/Gsn7TIekpigJyTH s8X+fZyy/MSCImmnb3wotjcVpPRjBDDtQskQMTyhNg1+9SEzXasXkZPNUVGxbeWxTfSp LwtA== X-Gm-Message-State: AOPr4FUwMIQ9zNN+EZLOxjETn5C768zRzi5MdblhG6hgPmhu/QqYYNFpDNUZP5yxohBz0ZCWujqqqHBV/BV//w== MIME-Version: 1.0 X-Received: by 10.129.160.194 with SMTP id x185mr9709274ywg.130.1462476654595; Thu, 05 May 2016 12:30:54 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Thu, 5 May 2016 12:30:54 -0700 (PDT) In-Reply-To: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Date: Thu, 5 May 2016 15:30:54 -0400 X-Google-Sender-Auth: wO4qHKazzL0sJOBR3LJ9Df7qfF4 Message-ID: From: Christopher Morrow To: Matthias Waehlisch Content-Type: multipart/alternative; boundary=94eb2c0876667d55aa05321d6181 Archived-At: Cc: sidr , Sandra Murphy Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 19:30:58 -0000 --94eb2c0876667d55aa05321d6181 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2016 at 12:01 PM, Matthias Waehlisch < m.waehlisch@fu-berlin.de> wrote: > Hi Chris, > > I'm not sure if I get your point. > > =E2=80=8Bi might not either.=E2=80=8B > On Thu, 5 May 2016, Christopher Morrow wrote: > > > I think it's an interesting topic to discuss, I'm a little worried > > that: "Because the third party said things are 'ok' I'll believe > > things are ok!" > > > > mostly because I don't see a clear method to ensure that 'third party' > has: > > 1) up-to-date information > > > Same with RTR cache server. > > =E2=80=8Bexcept I run the server and can get some data about how updated/et= c it is with respect to collection of roa/etc data.=E2=80=8B > > 2) my best interest at heart > > > If you peer with a route server, you should establish a trust relation > anyway. > > =E2=80=8Bmaybe?=E2=80=8B how is an IX different from any direct peering? wh= y would I trust elbonia telecom over elbonia-ix over myself? =E2=80=8B > > 3) current/appropriate configuration > > > Same with RTR cache erver. > > =E2=80=8Bbut that's something I can control, not trust the right thing ha= ppened > elsewhere (and I can monitor and maintain it)=E2=80=8B > > Cheers > matthias > > > -- > Dr. Matthias Waehlisch > . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST > . Takustr. 9, D-14195 Berlin, Germany > .. mailto:m.waehlisch@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl > :. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net --94eb2c0876667d55aa05321d6181 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ma= y 5, 2016 at 12:01 PM, Matthias Waehlisch <m.waehlisch@fu-berlin.de= > wrote:
Hi Chris,

=C2=A0 I'm not sure if I get your point.


=E2=80=8Bi might not either.=E2=80= =8B

=C2=A0
On Thu, 5 May 2016, Christopher Morrow wrote:

> I think it's an interesting topic to discuss, I'm a little wor= ried
> that: "Because the third party said things are 'ok' I'= ;ll believe
> things are ok!"
>
> mostly because I don't see a clear method to ensure that 'thir= d party' has:
> =C2=A0 1) up-to-date information
>
=C2=A0 Same with RTR cache server.


=E2=80=8Bexcept I run the server a= nd can get some data about how updated/etc it is with respect to collection= of roa/etc data.=E2=80=8B

=C2=A0
> =C2=A0 2) my best interest at heart
>
=C2=A0 If you peer with a route server, you should establish a trust= relation
anyway.


=E2=80=8Bmaybe?=E2=80=8B how is an IX different from any d= irect peering? why would I trust elbonia telecom over elbonia-ix over mysel= f?
=E2=80=8B
=C2=A0
> =C2=A0 3) current/appropriate configuration
>
=C2=A0 Same with RTR cache erver.

=E2= =80=8Bbut that's something I can control, not trust the right thing hap= pened elsewhere (and I can monitor and maintain it)=E2=80=8B

Cheers
=C2=A0 matthias


--
Dr. Matthias Waehlisch
.=C2=A0 Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.=C2=A0 Takustr. 9, D-14195 Berlin, Germany
.. mailto:m.waehlisch@fu-berlin= .de .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net

--94eb2c0876667d55aa05321d6181-- From nobody Thu May 5 14:17:03 2016 Return-Path: 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 6F65712D0C0 for ; Thu, 5 May 2016 14:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 Hm6XUP9XlzqX for ; Thu, 5 May 2016 14:16:59 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 C367512D0BD for ; Thu, 5 May 2016 14:16:59 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g133so145066630ywb.2 for ; Thu, 05 May 2016 14:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=y87LZd3xWmFtTABxK/GZk6gdM6QlLyABuT+VkQBnUaA=; b=I5QKMOhE/Cz9RT4b6vq5Yqa2rMPz7ahtrCGRar/Ub69cXEc8x9tV7OLV/JK9AfxWU5 oOYToGFu/6YxQTEgMNIU9K2RNU1y5H+zNDVvo8GUbLxhBoJFXS/ERWSiGWALfnmip/mn xCxkr6AwpLDVbnlrHl+CYF6nF4DYG8VzbDWVf7m/dYaiQApgmvZhuAYrQSti/5YRfOUX ktcoCN/xWbEflv4sEK49ERhyhLX/AjPKDy5HBSZzq/+UB/xj0VHj2vzfdMaYa9OaGGPL cyGvq36h7DcRNylx+GVegE4W/Q9oF2S3Jxp5S5j++CgoQnrUMh1jbavsN0bDTFmF7WuA CApg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=y87LZd3xWmFtTABxK/GZk6gdM6QlLyABuT+VkQBnUaA=; b=TK6XCfQUvt3etpmOkIq4hxelOA+10b+jHy13JQhOBKL1jHL8ZRGlX/4EJlcZbY/WaX DSp9aFSrosNlPUBSqOeORvWQdlRWExkT6YECKUFobXd9+03rWTBLf/RbA+23oVY0dvm5 p1GJwB3Wt8oveEVGzJ5UiYAmknnwh4AsE423E3hLHrMtgd+QOaJHWJBVMh6FWQ9UYmtO BIzU+EMhgcDoxnyQVVZoSqiLBUq2EZ44MNZaaqV2UkW0ys7KQ1cg8l15I94Ll5xemt+Y P5sq6by8tvSaum55iI2RAvpjUYj6HZN9lfl/U2NhN2glP6zZ8QPx9g+Gb4ITyWhzkAkR nbyA== X-Gm-Message-State: AOPr4FX+mAD9fKIDtlnLfrW+ZrqOa7hSFm6JJ12BRiCpvy72WWrm8r+qBD7j5oeRa1Wg9g== X-Received: by 10.37.202.196 with SMTP id a187mr10050730ybg.121.1462483019044; Thu, 05 May 2016 14:16:59 -0700 (PDT) Received: from ?IPv6:2001:13c7:7003:100:788b:c742:dc07:a0c3? ([2001:13c7:7003:100:788b:c742:dc07:a0c3]) by smtp.googlemail.com with ESMTPSA id q132sm6753417ywc.21.2016.05.05.14.16.57 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2016 14:16:58 -0700 (PDT) References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> To: sidr@ietf.org From: "Carlos M. Martinez" Message-ID: <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> Date: Thu, 5 May 2016 17:16:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:17:01 -0000 hey! On 5/5/16 3:30 PM, Christopher Morrow wrote: > > I think it's an interesting topic to discuss, I'm a little worried > > that: "Because the third party said things are 'ok' I'll believe > > things are ok!" > > > > mostly because I don't see a clear method to ensure that 'third party' has: > > 1) up-to-date information > > > Same with RTR cache server. > > > ​except I run the server and can get some data about how updated/etc it > is with respect to collection of roa/etc data.​ Not always. In a couple of IXs I know the RTR server is shared and is provided as a service to the IXs members. They trust each other enough to do this, so not trusting the route server would be kind of silly. In any case, you, personally as an individual IX member, are free to have any misgivings about the operational expertise of the IX and you can adjust your BGP configs accordingly (de-prefing whatever you learn from elbonia-ix, ignoring validation state, overwriting communities). I just don't see an argument against what the draft proposes in the scenario you describe. However, if you dis-trust a particular IX too much, maybe you just should de-peer them. But we disgress :-) -Carlos PS: I loved the name Elbonia, Can I license it from you ? :-) From nobody Thu May 5 15:51:57 2016 Return-Path: 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 B826B12D825 for ; Thu, 5 May 2016 15:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 w6GZSmC25llB for ; Thu, 5 May 2016 15:51:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492ED12B013 for ; Thu, 5 May 2016 15:51:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ayS7d-0007bi-J0; Thu, 05 May 2016 22:51:53 +0000 Date: Fri, 06 May 2016 07:51:51 +0900 Message-ID: From: Randy Bush To: Matthias Waehlisch In-Reply-To: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 22:51:57 -0000 >> mostly because I don't see a clear method to ensure that 'third party' h= as: >> =A0 1) up-to-date information > Same with RTR cache server. i would not load routers from rpki caches i do not own and control >> =A0 2) my best interest at heart > If you peer with a route server, you should establish a trust relation = > anyway. in my heart i agree with chris, a prudent operator does not outsource security. otoh, i also do not think a prudent operator outsources bgp, i.e. uses a route server. putting the two together, if you are willing to outsource bgp to a route server, then outsourcing bgp security to the route server is not much of a leap. chris, think of it as shooting yourself in the foot with a two-barrelled gun instead of one with one barrel. :) randy From nobody Thu May 5 19:20:42 2016 Return-Path: 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 5EE8A12D107 for ; Thu, 5 May 2016 19:20:41 -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 7Uz0CxzqySz3 for ; Thu, 5 May 2016 19:20:39 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 916B912D12F for ; Thu, 5 May 2016 19:20:38 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id j74so156305352ywg.1 for ; Thu, 05 May 2016 19:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Zx+7AOFbJiHsMw4o82IW1QYtNnjWls/w6Ei4eeViIrc=; b=UbfcnFRspWa86EaRUURGLyA2EfuCnb2aDc9PyviIA+CnceMlIYuuieFQ8HA08oumAi a8NqcZHDygoMd3MJDMzfgkQxvjsxwtARIX88UmGe0gg94yFwmRFVWyutMKrNOd3wbnU6 BVsoaEVzhjvWRqTdoutKr5jugow2o4O1C0lkc+scwdYIqQZFRoZVwJAP3qZRjUioWYNG fnwHvQ4stlH2fcjmbnexcHT5uXDPRPCw+Y6BJ5WJ1JonUJBQ5PtMGMXFk6u834a4cgEm v5HbbuajkW7XapkDK4nmNa5GtPe/17rJesISV5R/V0TfNuMHk9J5+EH9zyc6FOiYlHqf jNVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Zx+7AOFbJiHsMw4o82IW1QYtNnjWls/w6Ei4eeViIrc=; b=ZL4MqC9+AMMqiGFuxXHfe7pt2mqOqCZLtsH7m1RV4cdUEbsxNKrmaPKXM0ceaNBAVj hwBn8fIq0eAS0/xacQg7Mw/w4oqwxjnkAAoCirBrNdswpqJWps8NQT9e6et2uWL82w6Z S+ay1Aoxn/SklNK3DtNwwy/C9t43rgWT8mmk1f4BTeOqwbWbkNYWWKkOdvR3NQWHSrF7 xaxpc7oEhUr3uL0eXeGoKBXRGRYVNtqOiY5Q6+pZdDIJaU6k7uT9afYL6+2sRkKfDCGW rKVuMATD6IN8aA6C+sXqobMCNF/OESTyA8L1I5qMjGjGhhllZrteG2xXbEM3l7p2nAsf EtCg== X-Gm-Message-State: AOPr4FXy104Y++ss9Fz+nay+0x1BlP0LhSHcUoEEJfn/2pnuLtWmcIA/bm2jd6am37A74seKt3cx2kINBYbgaQ== MIME-Version: 1.0 X-Received: by 10.37.3.213 with SMTP id 204mr9964595ybd.129.1462501237869; Thu, 05 May 2016 19:20:37 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Thu, 5 May 2016 19:20:37 -0700 (PDT) In-Reply-To: <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> Date: Thu, 5 May 2016 22:20:37 -0400 X-Google-Sender-Auth: PAuMY6fs4gVc2M9SV7HH9Z47mjA Message-ID: From: Christopher Morrow To: Carlos Martinez Content-Type: multipart/alternative; boundary=001a11c01262c4584b0532231a9f Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 02:20:41 -0000 --001a11c01262c4584b0532231a9f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2016 at 5:16 PM, Carlos M. Martinez wrote: > hey! > > On 5/5/16 3:30 PM, Christopher Morrow wrote: > > > I think it's an interesting topic to discuss, I'm a little worrie= d > > > that: "Because the third party said things are 'ok' I'll believe > > > things are ok!" > > > > > > mostly because I don't see a clear method to ensure that 'third > party' has: > > > 1) up-to-date information > > > > > Same with RTR cache server. > > > > > > =E2=80=8Bexcept I run the server and can get some data about how update= d/etc it > > is with respect to collection of roa/etc data.=E2=80=8B > > Not always. In a couple of IXs I know the RTR server is shared and is > provided as a service to the IXs members. > > They trust each other enough to do this, so not trusting the route > server would be kind of silly. > > =E2=80=8Bsure, but I dont' always use the RS at the IX.=E2=80=8B > In any case, you, personally as an individual IX member, are free to > have any misgivings about the operational expertise of the IX and you > can adjust your BGP configs accordingly (de-prefing whatever you learn > from elbonia-ix, ignoring validation state, overwriting communities). I > just don't see an argument against what the draft proposes in the > scenario you describe. > > However, if you dis-trust a particular IX too much, maybe you just > should de-peer them. But we disgress :-) > =E2=80=8Byea, so... I didn't REALLY want to rathole the conversation. I'm p= erfectly happy if consenting adults want to do this, that's cool. I may not? I may in some places because I can't solve my problem other ways? I don't think bending things like this is particularly bad, as long as people understand what they walked into/on. > > -Carlos > > PS: I loved the name Elbonia, Can I license it from you ? :-) > > =E2=80=8Babsolutely... Elbonia and Westonia.. they are bad places, (dependi= ng on your perspective of course.. if you are elbonian, you dislike westonians... and vice/versa) :)=E2=80=8B > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a11c01262c4584b0532231a9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ma= y 5, 2016 at 5:16 PM, Carlos M. Martinez <carlosm3011@gmail.com>= ; wrote:
hey!

On 5/5/16 3:30 PM, Christopher Morrow wrote:
>=C2=A0 =C2=A0 =C2=A0> I think it's an interesting topic to discu= ss, I'm a little worried
>=C2=A0 =C2=A0 =C2=A0> that: "Because the third party said thing= s are 'ok' I'll believe
>=C2=A0 =C2=A0 =C2=A0> things are ok!"
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> mostly because I don't see a clear method = to ensure that 'third party' has:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A01) up-to-date information
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Same with RTR cache server.
>
>
> =E2=80=8Bexcept I run the server and can get some data about how updat= ed/etc it
> is with respect to collection of roa/etc data.=E2=80=8B

Not always. In a couple of IXs I know the RTR server is shared and i= s
provided as a service to the IXs members.

They trust each other enough to do this, so not trusting the route
server would be kind of silly.


=E2=80=8Bsure, but I dont' always use the RS at the IX= .=E2=80=8B

=C2=A0
In any case, you, personally as an individual IX member, are free to
have any misgivings about the operational expertise of the IX and you
can adjust your BGP configs accordingly (de-prefing whatever you learn
from elbonia-ix, ignoring validation state, overwriting communities). I
just don't see an argument against what the draft proposes in the
scenario you describe.

However, if you dis-trust a particular IX too much, maybe you just
should de-peer them. But we disgress :-)

=E2=80=8Byea, so..= . I didn't REALLY want to rathole the conversation. I'm perfectly h= appy if consenting adults want to do this, that's cool. I may not? I ma= y in some places because I can't solve my problem other ways?

I don't think bending things l= ike this is particularly bad, as long as people understand what they walked= into/on.

=C2=A0

-Carlos

PS: I loved the name Elbonia, Can I license it from you ? :-)

<= br>
=E2=80= =8Babsolutely... Elbonia and Westonia.. they are bad places, (depending on = your perspective of course.. if you are elbonian, you dislike westonians...= and vice/versa) :)=E2=80=8B

=C2=A0


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

--001a11c01262c4584b0532231a9f-- From nobody Fri May 6 12:35:11 2016 Return-Path: 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 1422112D5E2 for ; Fri, 6 May 2016 12:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 rzglOliTxt4D for ; Fri, 6 May 2016 12:35:09 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 970E112D52C for ; Fri, 6 May 2016 12:35:09 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g133so200884024ywb.2 for ; Fri, 06 May 2016 12:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=S1TYkBgNSMGV5TYGkeQ3V6u6B4jqvCHP7aLco5naBdg=; b=qxBFgG3tMMp0E7f7tcBuN/5z+ZgVREKeSJmPwR0Vy8pdAbBpXYAW2UDZgznwabp+rK tXXaftYbQs8ROfNBvJ0sHtrOjmxqkRJ5xF4oadxm4apZwN1A4qKJK+BA0pQmducbvHzR uns9dlW0foGhglFbVfDMXTU40CvcDvmDo/Bq5cbH+O1cY/Rfn/YPpZYeg1BTLHePUQE5 +VnuSLLTKsP4wB94CUDi8vjbXHmG7RBs2UpMbC/XeDkAAH2BSplq6Le45fIguq0T16gg TNVQ+Mrj7mwGOxessIE7jSkuFHg7nDapdGSmw22kQDJSVToGm9AwI9tKT+QKUdbnl2dC ysug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=S1TYkBgNSMGV5TYGkeQ3V6u6B4jqvCHP7aLco5naBdg=; b=MNHT25jATK+IeD/pVocT/ckT/CcwFsf37poLQlyOFbNMc6mpymVSEBX+xO5g99xZhs ucX2Q2YszgXTi1kyQEapFzTPRXOZNdjrM0ubrjDI2Vr3A/b+ianTeJ2UbXx3EcvLgXpQ K5q6OlnGlvJj81Lr6RfxZvQHQ6TLskWkCxzcmA83/pMJcOVFC5QHu331bOM+cjkwGRNM yXlmkK1eokZ54MGvQZxBWI6herKdgAanB/WRbmtlqMdNDaYUwW14FlBCOmVfSRudb+5Y n8RlGc6rYjlZ2/eNOZUzLJw2k0shvSmGDKtNVlWlrO1fYm4GYCihgwheR4U5OFJQd2yF RlFA== X-Gm-Message-State: AOPr4FW2nO/3X8LD6aXca60lfVvwWW5xoU5mLDcSozfw0LYw2O++D//zYbyMZMCkXydXvg== X-Received: by 10.13.230.193 with SMTP id p184mr13324763ywe.81.1462563308934; Fri, 06 May 2016 12:35:08 -0700 (PDT) Received: from [190.112.54.14] ([190.112.54.14]) by smtp.googlemail.com with ESMTPSA id l128sm9689338ywd.5.2016.05.06.12.35.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2016 12:35:08 -0700 (PDT) References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> To: Randy Bush , Matthias Waehlisch From: "Carlos M. Martinez" Message-ID: <152abece-c6cc-4715-bbd7-a86da29e15e3@gmail.com> Date: Fri, 6 May 2016 15:35:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 19:35:11 -0000 Hi! On 5/5/16 6:51 PM, Randy Bush wrote: >>> mostly because I don't see a clear method to ensure that 'third party' has: >>> 1) up-to-date information >> Same with RTR cache server. > > i would not load routers from rpki caches i do not own and control Me neither. Yet people do it. Whether they are going to be majority or not, time will tell. > >>> 2) my best interest at heart >> If you peer with a route server, you should establish a trust relation >> anyway. > > in my heart i agree with chris, a prudent operator does not outsource > security. > > otoh, i also do not think a prudent operator outsources bgp, i.e. uses a > route server. > > putting the two together, if you are willing to outsource bgp to a route > server, then outsourcing bgp security to the route server is not much of > a leap. Agree 100%. > > chris, think of it as shooting yourself in the foot with a two-barrelled > gun instead of one with one barrel. :) :-) -C. From nobody Fri May 6 12:45:04 2016 Return-Path: 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 B4E8A12D565 for ; Fri, 6 May 2016 12:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 sQdevPvF9TjE for ; Fri, 6 May 2016 12:45:00 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 2F6DC12B017 for ; Fri, 6 May 2016 12:45:00 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n63so66257003qkf.0 for ; Fri, 06 May 2016 12:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ItL2uuCQsVhzLcDp5fY5fA/1RKqUVzuPxsmOP3bY7Kc=; b=Fl7EKZd7xHUs5mGbRghdQ3O00cwnvsoIvJCd8OPXwp4SHxGsHVE1utAkWq2eOilf2r Yc49B2FU1AtZzJNn+w7KQhG4JobRv6wMdhYF+1rjEbEyjtX3KH282fYP+Sd3lBco/5Sm N69iAJRN+l50HDOhHfQZ9rVhYK/gJnvDRKyYPe6+pWCs5pCRur24mPmn4q7D7yJE+82g MDrGTw5cbq8zGR/jqOmoltINU7wRsZYwVgs8OM2Y5OGuKO4vEIQIACDMlT3qKczP4SDb cEbnSvRnYTTAO/5X8aXwGcL5CU9OiJt3fcEm3Wbg1d30kjcTK1BzapNK8nF5ib6zZG2r lEqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ItL2uuCQsVhzLcDp5fY5fA/1RKqUVzuPxsmOP3bY7Kc=; b=ZzCGudVXlNC0nFjCAIyHZ/AW9ALL9dzffsOenEbuEYddb93hYdCfgK7xClYa5sU3zH GE/kXEZjsWyMqFGc1ycWkPQIyjSEXXKR1c1DSJ/SrHoVkMLJZJRMoljNAwKovazGfBPG k+ApdpCIWAZpZ8STLmikaYsBKDIy7ZD7mG7u/7KFjFlz+bltoRwkF4cO6wD5iplSvi+j 7tsT4Q6XU9XCac3V8DbMYb3Wr+50cMG7sd5Lb2L3h8IERSdZ9LEEUHR9sMQbYvONiK7V oK1iMGCA+srYPz4YiDkj6Jvx4RHIm3li6rZ78ax9j9jPTbACdVsnThwioBqEBBnLP6Io S6TA== X-Gm-Message-State: AOPr4FWuFJGuNAvUI+5wg8CrRIKSW18PXMLeYs18G7gCCg2Rsb2LP32iQ7uYUahNIJd+S4u4FLdOAQPOov6mrVS+ X-Received: by 10.55.27.215 with SMTP id m84mr2995205qkh.124.1462563899289; Fri, 06 May 2016 12:44:59 -0700 (PDT) MIME-Version: 1.0 References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> In-Reply-To: From: Warren Kumari Date: Fri, 06 May 2016 19:44:49 +0000 Message-ID: To: Christopher Morrow , Carlos Martinez Content-Type: multipart/alternative; boundary=001a11440cf0adea7b053231b138 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 19:45:03 -0000 --001a11440cf0adea7b053231b138 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2016 at 10:20 PM Christopher Morrow wrote: > On Thu, May 5, 2016 at 5:16 PM, Carlos M. Martinez > wrote: > >> hey! >> >> On 5/5/16 3:30 PM, Christopher Morrow wrote: >> > > I think it's an interesting topic to discuss, I'm a little worri= ed >> > > that: "Because the third party said things are 'ok' I'll believe >> > > things are ok!" >> > > >> > > mostly because I don't see a clear method to ensure that 'third >> party' has: >> > > 1) up-to-date information >> > > >> > Same with RTR cache server. >> > >> > >> > =E2=80=8Bexcept I run the server and can get some data about how updat= ed/etc it >> > is with respect to collection of roa/etc data.=E2=80=8B >> >> Not always. In a couple of IXs I know the RTR server is shared and is >> provided as a service to the IXs members. >> >> They trust each other enough to do this, so not trusting the route >> server would be kind of silly. >> >> > =E2=80=8Bsure, but I dont' always use the RS at the IX.=E2=80=8B > > ... and you don't have to trust the RS if you do. This feel like a prefect being the enemy of the good type discussion -- you shouldn't use RS, and you should do your own validation. You should also always brush your teeth and ear yer veggies -- but, we know some people will not listen to / follow this advice. Some people do use route servers, and won't do their own validation - I'd rather that they have the information available to make a decision than not... > > >> In any case, you, personally as an individual IX member, are free to >> have any misgivings about the operational expertise of the IX and you >> can adjust your BGP configs accordingly (de-prefing whatever you learn >> from elbonia-ix, ignoring validation state, overwriting communities). I >> just don't see an argument against what the draft proposes in the >> scenario you describe. >> > > >> However, if you dis-trust a particular IX too much, maybe you just >> should de-peer them. But we disgress :-) >> > > =E2=80=8Byea, so... I didn't REALLY want to rathole the conversation. I'm > perfectly happy if consenting adults want to do this, that's cool. I may > not? I may in some places because I can't solve my problem other ways? > > I don't think bending things like this is particularly bad, as long as > people understand what they walked into/on. > Yup. W > > > >> >> -Carlos >> >> PS: I loved the name Elbonia, Can I license it from you ? :-) >> >> > =E2=80=8Babsolutely... Elbonia and Westonia.. they are bad places, (depen= ding on > your perspective of course.. if you are elbonian, you dislike westonians.= .. > and vice/versa) :)=E2=80=8B > > > >> >> >> _______________________________________________ >> 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 > --001a11440cf0adea7b053231b138 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , May 5, 2016 at 10:20 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, May 5, 2016 at 5:16 PM, Carlos M. Martinez <c= arlosm3011@gmail.com> wrote:
=E2=80=8Bsure, but I dont' always use th= e RS at the IX.=E2=80=8B


... and you don't have to trust the RS if you do.
=

This feel like a prefect being the enemy of the good ty= pe discussion -- =C2=A0you shouldn't use RS, and you should do your own= validation. You should also always brush your teeth and ear yer veggies --= but, we know some people will not listen to / follow this advice.
Some people do use route servers, and won't do their own validation -= I'd rather that they have the information available to make a decision= than not...
=C2=A0
=C2=A0
In any case, you, personally as an individual IX member, are free to
have any misgivings about the operational expertise of the IX and you
can adjust your BGP configs accordingly (de-prefing whatever you learn
from elbonia-ix, ignoring validation state, overwriting communities). I
just don't see an argument against what the draft proposes in the
scenario you describe.
=
=C2=A0
=

However, if you dis-trust a particular IX too much, maybe you just
should de-peer them. But we disgress :-)

=E2= =80=8Byea, so... I didn't REALLY want to rathole the conversation. I= 9;m perfectly happy if consenting adults want to do this, that's cool. = I may not? I may in some places because I can't solve my problem other = ways?

I don't think b= ending things like this is particularly bad, as long as people understand w= hat they walked into/on.
Yup.
W
=C2=A0

=C2=A0

-Carlos

PS: I loved the name Elbonia, Can I license it from you ? :-)


=E2=80=8Babsolutely...= Elbonia and Westonia.. they are bad places, (depending on your perspective= of course.. if you are elbonian, you dislike westonians... and vice/versa)= :)=E2=80=8B

=C2=A0


_______________________________________________
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
--001a11440cf0adea7b053231b138-- From nobody Fri May 6 13:06:07 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6469B12B017; Fri, 6 May 2016 13:06:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506200605.7476.83074.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 13:06:05 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] sidr - New Meeting Session Request for IETF 96 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 20:06:05 -0000 A new meeting session request has just been submitted by Sandra L. Murphy, a Chair of the sidr working group. --------------------------------------------------------- Working Group Name: Secure Inter-Domain Routing Area Name: Routing Area Session Requester: Sandra Murphy Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: opsec idr grow saag rtgwg rtgarea Second Priority: dane i2rs isis spring trill Special Requests: --------------------------------------------------------- From nobody Fri May 6 14:33:42 2016 Return-Path: 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 E923F12D512 for ; Fri, 6 May 2016 14:33:40 -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 uaeZMrNcOCjy for ; Fri, 6 May 2016 14:33:39 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 242F812B01F for ; Fri, 6 May 2016 14:33:39 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id u10so57761336igr.1 for ; Fri, 06 May 2016 14:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w4nSBMYU7xpncTeTG7L+29dYQSl31876DL/Pw+DnVX0=; b=uuqaPlX05oYndMqk78UiYvlynAu4h3EW/SXRJZz4zajXMgX7BCpFPvnBwuGcN+0FBL PUXJ88qgDPgHqxFIgE0YY5KsAk4zZ224oZ96B6NH3RTmSaLtwOS4TKzwqeJ7HzrZW3E/ huoNp+wFFha/WGTFaLOi5iA+Nz3RjhrzKtwB/D/sLsFiMNtfLXQlXHiCAVInO1HZ0gQH Asj8zHz/JMqtG6upeso+CS9q/asoLbplI1pggDhaM6zljY/TLVTgeEMswAkRVKQZi0pD qx0+o+xeUyMxOb2stEM6JPfTDDJMicH75c8byjG7UhoyezZ8Zg7B4cAJa6q7WRdEOZfx FY+Q== 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:from:date :message-id:subject:to:cc; bh=w4nSBMYU7xpncTeTG7L+29dYQSl31876DL/Pw+DnVX0=; b=SwLvZKT0AuKhzjUW8D5WZpOC1Oi9zxcPJ1kHHNI+5Mm4ySqCCu1mlhD4NjNMFgUKlt D2jdms12eIXwuczX3HrFuXsccbFf8tfxO/0xfR+dpT0XUoIiIEux0GQtATPaCBA4zrNV 1JS5Qo5uBTeC+J1TZygi3pluP+xQ+JqvEFTK2YfjnpOL4SUbwNYqVfJoLVnTD8aE67M3 1I+SdeY2piPLRW46KffPnvswM8bVSyciLEDbBgh3VdVaLv/of0bN4SUKG2No5tZpF0Q8 zZkY7ydtFk+3RG62+cPDhOww/8VulVjfw4vz3QwlDQfITZTQOnXs0dsX2X8jaeKH/L2W iIRg== X-Gm-Message-State: AOPr4FVL07L9njfRcKWQSyFqnxd8spIR8s3S91Cy7olgGU6pcR0Lhn4UK3cwr06KuahP2hGtO2AWow+BskO94Q== X-Received: by 10.50.186.163 with SMTP id fl3mr12656731igc.27.1462570418509; Fri, 06 May 2016 14:33:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.211.65 with HTTP; Fri, 6 May 2016 14:33:19 -0700 (PDT) In-Reply-To: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> From: Arturo Servin Date: Fri, 6 May 2016 17:33:19 -0400 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=14dae93404014126910532333695 Archived-At: Cc: Carlos Martinez , "sidr@ietf.org" Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 21:33:41 -0000 --14dae93404014126910532333695 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 6, 2016 at 3:44 PM, Warren Kumari wrote: > =E2=80=8Bsure, but I dont' always use the RS at the IX.=E2=80=8B >> >> > ... and you don't have to trust the RS if you do. > > This feel like a prefect being the enemy of the good type discussion -- > you shouldn't use RS, and you should do your own validation. You should > also always brush your teeth and ear yer veggies -- but, we know some > people will not listen to / follow this advice. > Some people do use route servers, and won't do their own validation - I'd > rather that they have the information available to make a decision than > not... > > 100% agree with Warren. I support the adoption of the document but I suggest to add text to guide the adopters in the multiple issues that implementing it might arise. Regards as --14dae93404014126910532333695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, May 6, 2016 at 3:44 PM, Warren Kumari <warren@kumari.net> wrote:
=E2=80=8Bsure, but I dont' always use the RS at the IX.=E2=80=8B

... an= d you don't have to trust the RS if you do.

Th= is feel like a prefect being the enemy of the good type discussion -- =C2= =A0you shouldn't use RS, and you should do your own validation. You sho= uld also always brush your teeth and ear yer veggies -- but, we know some p= eople will not listen to / follow this advice.
Some people do use= route servers, and won't do their own validation - I'd rather that= they have the information available to make a decision than not...
=C2=A0

100% agree with Warren.

I support the adoption of the d= ocument but I suggest to add text to guide the adopters in the multiple iss= ues that implementing it might arise.

<= /div>
Regards
as<= /div>
--14dae93404014126910532333695-- From nobody Fri May 6 15:06:16 2016 Return-Path: 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 4155612D0DA for ; Fri, 6 May 2016 15:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Nvpo6raREla1 for ; Fri, 6 May 2016 15:06:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0093A12D0BD for ; Fri, 6 May 2016 15:06:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aynsy-0005Vj-1a; Fri, 06 May 2016 22:06:12 +0000 Date: Sat, 07 May 2016 07:06:10 +0900 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 22:06:15 -0000 > Some people do use route servers, and won't do their own validation - > I'd rather that they have the information available to make a decision > than not... this glibly glosses over that, by outsourcing origin validation, an attack vector is introduced. i presume i do not need to describe it. so it needs to be big in the sec cons. randy From nobody Fri May 6 15:28:22 2016 Return-Path: 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 841D612D1A7 for ; Fri, 6 May 2016 15:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 A0NUCkzHti-y for ; Fri, 6 May 2016 15:28:19 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix.ams-ix.net [IPv6:2001:67c:1a8:a101::70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC8F12D13C for ; Fri, 6 May 2016 15:28:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from [192.168.1.10] (unknown [92.110.22.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: aristidis) by deliverix.ams-ix.net (Postfix) with ESMTPSA id E651C47FAE; Sat, 7 May 2016 00:28:16 +0200 (CEST) Message-ID: <572D1A7E.9020208@ams-ix.net> Date: Sat, 07 May 2016 00:28:14 +0200 From: Aris Lambrianidis User-Agent: Postbox 4.0.8 (Windows/20151105) MIME-Version: 1.0 To: Randy Bush References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 22:28:21 -0000 Randy Bush wrote: > this glibly glosses over that, by outsourcing origin validation, an > attack vector is introduced. i presume i do not need to describe it. > so it needs to be big in the sec cons. Is it bigger than the attack vector allowed for when not doing origin validation at all? Kind regards, Aris Lambrianidis From nobody Fri May 6 15:32:19 2016 Return-Path: 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 361E512D12F for ; Fri, 6 May 2016 15:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vklTHflnt6UC for ; Fri, 6 May 2016 15:32:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1443F12D0C0 for ; Fri, 6 May 2016 15:32:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ayoIA-0005Zf-Jo; Fri, 06 May 2016 22:32:15 +0000 Date: Sat, 07 May 2016 07:32:13 +0900 Message-ID: From: Randy Bush To: Aris Lambrianidis In-Reply-To: <572D1A7E.9020208@ams-ix.net> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> <572D1A7E.9020208@ams-ix.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 22:32:17 -0000 >> this glibly glosses over that, by outsourcing origin validation, an >> attack vector is introduced. i presume i do not need to describe it. >> so it needs to be big in the sec cons. > Is it bigger than the attack vector allowed for when not doing origin > validation at all? now we're comparing the size of the guns used to shoot yourself in the foot? my point was that it needs to go in the sec cons. not the size of the type to be used. randy From nobody Fri May 6 15:34:00 2016 Return-Path: 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 82A5B12D12F for ; Fri, 6 May 2016 15:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 jIez2B4l2LX8 for ; Fri, 6 May 2016 15:33:56 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 A0D1212B01D for ; Fri, 6 May 2016 15:33:56 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id f92so63830026qgf.0 for ; Fri, 06 May 2016 15:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yulkEym838kIAkJlAz0KwbG2ofElCBgeKEiEsNo0RmQ=; b=n5he+uloD1eh3ToCdixu4Cz3JG5i+bxT9Bc26p+CP9wkiU3Gk7ISsGwKNp4yaf4DL2 y+2wA8B2eZldKXdFnpsrw8EU0s1ELqpEIwQM03AIk+RopvP2jWzDOCBYJ4F5xpupOmd/ bodDGz+uGBsNv2QBP+T0ltShKLKU+ssm5jgTMcQ6UgPuBijGQkl1Xmr06yqUCr5lF8LY Aj058PYUGLsEcQelDGYzEakawus7JrFur4K3BUj/XFc5aJFpOz1HVN6p+RR/4mucmihb 8iG2fkIcJr02heoWYFBHwEdbQbvlMc4r26nfUAaPTywj75hXXJONHe2oc8J1VjOPwBs0 Ufug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yulkEym838kIAkJlAz0KwbG2ofElCBgeKEiEsNo0RmQ=; b=V9P2PPIThrxw++6HZGX4j2OpWZkcBQKgsKfE0atIVaBv3LuCZjuZwBdeA5NtoaEYXR uGWzqE8phqyDN4o3Av+FEueXMbEK90ed3qgLOL5mOmFCK8i1m5ic5hdz+W++M/gz451P w+Km2ALVBfocESrWbdHv/DaFRENSgVqFYW52LNUo3+6S2ogXC38s2x1OalLrQTBg158W iGqcsxh4sj/s+hAQch/0NEK5QcgoSsaGDEBRxe8wlmiPSCvP3J9ieuKj8DTlE8BMoxFf 8O7p7umvg/3swHeKqXGTCzdBEYK5Ua9gvaIN8/FeKVwBxmqCi05eWJnEQ7RP6Puvl8N9 ecew== X-Gm-Message-State: AOPr4FXfNVXgHF5M4ttIR2PenfJpjTTFkqqnYwwTG5bdYAt6sCI71XcsyTYkQiKpPrRJuDIlE8gdOoFZ8pfISljt X-Received: by 10.140.108.116 with SMTP id i107mr22048789qgf.36.1462574035787; Fri, 06 May 2016 15:33:55 -0700 (PDT) MIME-Version: 1.0 References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> In-Reply-To: From: Warren Kumari Date: Fri, 06 May 2016 22:33:46 +0000 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a113aadc2dc7fc20532340db7 Archived-At: Cc: sidr wg list Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 22:33:58 -0000 --001a113aadc2dc7fc20532340db7 Content-Type: text/plain; charset=UTF-8 On Fri, May 6, 2016 at 6:06 PM Randy Bush wrote: > > Some people do use route servers, and won't do their own validation - > > I'd rather that they have the information available to make a decision > > than not... > > this glibly glosses over that, by outsourcing origin validation, an > attack vector is introduced. Yup. > i presume i do not need to describe it. > so it needs to be big in the sec cons. > Yup, I fully agree. I had a flag set to mention that, but somehow lost it. It definitely needs to be stressed -- you really really really should do your own validation. If, for some reason you cannot / will not, having someone else doing your validation *might* be better than nothing, but it also might not be... W > > randy > --001a113aadc2dc7fc20532340db7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , May 6, 2016 at 6:06 PM Randy Bush <ra= ndy@psg.com> wrote:
> Som= e people do use route servers, and won't do their own validation -
> I'd rather that they have the information available to make a deci= sion
> than not...

this glibly glosses over that, by outsourcing origin validation, an
attack vector is introduced.=C2=A0

Yup.
=C2=A0
i presume i do not need = to describe it.
so it needs to be big in the sec cons.

= Yup, I fully agree. I had a flag set to mention that, but somehow lost it.<= /div>
It definitely needs to be stressed -- you really really really sh= ould do your own validation. If, for some reason you cannot / will not, hav= ing someone else doing your validation *might* be better than nothing, but = it also might not be...=C2=A0

W

randy
--001a113aadc2dc7fc20532340db7-- From nobody Fri May 6 15:45:49 2016 Return-Path: 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 4FF6412B017 for ; Fri, 6 May 2016 15:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 aqAUeujPgqHv for ; Fri, 6 May 2016 15:45:45 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix-1.ams-ix.net [185.55.136.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4791012B01D for ; Fri, 6 May 2016 15:45:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from [192.168.1.10] (unknown [92.110.22.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: aristidis) by deliverix.ams-ix.net (Postfix) with ESMTPSA id 360EC47FC2; Sat, 7 May 2016 00:45:41 +0200 (CEST) Message-ID: <572D1E93.1010105@ams-ix.net> Date: Sat, 07 May 2016 00:45:39 +0200 From: Aris Lambrianidis User-Agent: Postbox 4.0.8 (Windows/20151105) MIME-Version: 1.0 To: Randy Bush References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> <572D1A7E.9020208@ams-ix.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 22:45:47 -0000 Randy Bush wrote: > now we're comparing the size of the guns used to shoot yourself in the > foot? > > my point was that it needs to go in the sec cons. not the size of the > type to be used. > > randy To be clear, I wasn't advocating an opinion, I was providing food for thought from a different angle. I think the analogy here is that a new type gun (or as I would see it, tool) is provided. As with any gun or tool, security considerations certainly need to be addressed. Kind regards, Aris Lambrianidis From nobody Wed May 11 06:09:03 2016 Return-Path: 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 C8CB912DABE; Wed, 11 May 2016 06:08:56 -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 GCWLry13hLgN; Wed, 11 May 2016 06:08:50 -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 EE33D12DABF; Wed, 11 May 2016 06:08:49 -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 BB1098812B; Wed, 11 May 2016 06:08:49 -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 44DC0328081A; Wed, 11 May 2016 06:08:49 -0700 (PDT) To: ietf@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> From: Brian Haberman Message-ID: <57332EDB.9090609@innovationslab.net> Date: Wed, 11 May 2016 09:08:43 -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: <20160428225451.GE123284@main> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dcDBlgVhEs2Fn9bUgVu272K65i81F67Go" Archived-At: Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 13:08:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dcDBlgVhEs2Fn9bUgVu272K65i81F67Go Content-Type: multipart/mixed; boundary="ATbramsKuh9u6bCGbvlE0f87o6H69DDnA" From: Brian Haberman To: ietf@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Message-ID: <57332EDB.9090609@innovationslab.net> Subject: Re: [sidr] Last Call: (Securing RPSL Objects with RPKI Signatures) to Proposed Standard References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> In-Reply-To: <20160428225451.GE123284@main> --ATbramsKuh9u6bCGbvlE0f87o6H69DDnA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for the in-depth review and your efforts in creating another implementation of this draft. Responses to your comments are below... On 4/28/16 6:54 PM, Tom Harrison wrote: > Section 5 requires that an EE certificate be used for the signing of > the RPSL object. An EE certificate must contain an SIA extension that > points to an RPKI signed object (RFC 6487 [4.8.8.2]). The draft does > not define a profile for a new type of object, or specify an existing > one that may be used instead. There are a number of ways to deal with > this: for example, by defining a new profile and changing the > signature URL to suit, or by amending RFC 6487 such that object > pointers in EE certificates are optional. 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. Given the single-use nature of the key-pair (section 3.2, point #1), omitting the SIA is straightforward. >=20 > Section 4 specifies sets of attributes that must be signed. 'org' is > included as one of these attributes for the as-block, inet[6]num, and > route[6] object types. However, 'org' is not defined in either of the > principal RPSL RFCs (2622 and 4012), and there are current > implementations (e.g. APNIC's) that do not support it. I think the > references to 'org' should be omitted. Agreed. I will remove 'org' from the listed objects. >=20 > Section 4 specifies 'signature' as an attribute that must be signed. > 'signature' can appear multiple times in a single object, where e.g. > two different resource holders sign a route[6] object. Given that the > text doesn't explicitly state that only the newest 'signature' must be > signed, it would appear to require that any extant 'signature' > attributes be signed as well. That in turn would prevent previous > signers from re-signing the object independently of the subsequent > signers. I think the text should be changed so that only the new > signature attribute need be signed. Agreed. I will update the text to explicitly refer to the signature currently under construction. >=20 > Section 2.4 requires that "the Internet number resources present in > [RFC3779] extensions of the certificate referred to in the "c" field > of the signature must cover the resources in the primary key of the > object". This means that it's not possible to sign a route[6] object > for a route where one resource holder has the ASN and another the > prefix. In revision 8 (and earlier), the possibility of there being > multiple signatures, each with a certificate covering a subset of the > primary key resources, was explicitly permitted. I think that the > previous text here should be restored. 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 tex= t. >=20 > (The above points were the product of much discussion of this draft > with Tim and Oleg from RIPE, not that I'm speaking for them. We were > able to write interoperable prototype signer/validator > implementations, so the document is in pretty good shape on the > whole.) Thanks! Glad to hear this. Regards, Brian --ATbramsKuh9u6bCGbvlE0f87o6H69DDnA-- --dcDBlgVhEs2Fn9bUgVu272K65i81F67Go Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXMy7gAAoJEBOZRqCi7goqOCEIAK4lvoTbtMhi3sgrmzHxdAnQ Byehd4C9/vv9ZAD1i+1KUbj4x5epbRbhQVFKU0LJAFRgj/0/nS4l/oOr1mnYMh4q lVJQJnh/yC96kkZTXNPK2XIa1qan7bcavZetO28IFpYUfKiRHRk8c22HmkmY4IEy mBs2R7usAU3in9H95kalqMrBqqhss0WG/LBKlbh2D4MTZE+lywu/KC0qIAR8vXM4 QpWjWWNPT/BIXV5qGOdcNW9djbM+/t/PHCXdXzvZwcwjvFtfaryGh/+/jcOqHG+d 1roPCGpcJjvWqBCULH4bRJFAmqO461rGKUUaYyEwKREGmCUKbGzoOujvWLCkGS0= =/K6/ -----END PGP SIGNATURE----- --dcDBlgVhEs2Fn9bUgVu272K65i81F67Go-- From nobody Wed May 11 09:42:36 2016 Return-Path: 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 C9BC412D11F; Wed, 11 May 2016 09:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jMEglhwTYyOL; Wed, 11 May 2016 09:42:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D40612D09A; Wed, 11 May 2016 09:42:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b0XDO-0003QP-Bs; Wed, 11 May 2016 16:42:26 +0000 Date: Wed, 11 May 2016 18:42:25 +0200 Message-ID: From: Randy Bush To: Brian Haberman In-Reply-To: <57332EDB.9090609@innovationslab.net> References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IETF Disgust List , sidr wg list Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 16:42:35 -0000 > 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. > 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? randy From nobody Wed May 11 09:57:02 2016 Return-Path: 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 References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> From: Brian Haberman 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q475qe1u9EM6NbRnVEvS1qwN6jVb5NkVp" Archived-At: Cc: IETF Disgust List , sidr wg list Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 16:57:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q475qe1u9EM6NbRnVEvS1qwN6jVb5NkVp Content-Type: multipart/mixed; boundary="GATOeo6k8xDjrH9SgEvHfQI6cR96Nmwtn" From: Brian Haberman To: Randy Bush Cc: IETF Disgust List , sidr wg list Message-ID: <57336455.1040508@innovationslab.net> Subject: Re: [sidr] Last Call: (Securing RPSL Objects with RPKI Signatures) to Proposed Standard References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> In-Reply-To: --GATOeo6k8xDjrH9SgEvHfQI6cR96Nmwtn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 i= s >> omitted when a certificate is used to sign RPSL objects. >=20 > 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. >=20 >> 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. >=20 > this is gonna be really simple; no complications at all i am sure. >=20 > 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 --GATOeo6k8xDjrH9SgEvHfQI6cR96Nmwtn-- --Q475qe1u9EM6NbRnVEvS1qwN6jVb5NkVp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXM2RaAAoJEBOZRqCi7goqHV4H/i8tK9T9aHcCG16M/liZt3ij vBRN2YLjrJr0eba/6rn2nQZnl69b2aVSVUA9FCDC7laI+mqxPw5hGP2DoCH5NpRz vatTpfCF4dAb+YGAlqdM/RM7i3o5wL4BXH9mXu++33DR6IsVcuzlJt3+gZy9SIjE SfjIcXlHSzJPNk+kgH2ROX/N+v6NFeGMyDobUiqyGsRm7yzZyZz4YisG9mMaJWLQ M1Mc2ENlolBvA0hFg1Rjssa7B0w0FAm1LDD9eMVm6zFRY1CfhvE9XtM00ahNeYQF kPqQqM0tGBidG+f4jriA70/5FUdJLFk9hbhqK8eVKhktxs3/bnvKwALid+reQLU= =g34d -----END PGP SIGNATURE----- --Q475qe1u9EM6NbRnVEvS1qwN6jVb5NkVp-- From nobody Wed May 11 12:06:52 2016 Return-Path: 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 0656B12D75D; Wed, 11 May 2016 12:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 CxnDIJ4DyXsM; Wed, 11 May 2016 12:06:49 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09A812D593; Wed, 11 May 2016 12:06:21 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 039EF28B003D; Wed, 11 May 2016 15:06:21 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id F02B61F8055; Wed, 11 May 2016 15:06:20 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A1F2D816-639B-4372-B7EC-0E3884CA00A6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <57332EDB.9090609@innovationslab.net> Date: Wed, 11 May 2016 15:04:58 -0400 Message-Id: <6CD64C8F-F0AA-4042-B974-056F06CE5E0A@tislabs.com> References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr , sidr chairs , draft-ietf-sidr-rpsl-sig@ietf.org, Sandra Murphy Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:06:51 -0000 --Apple-Mail=_A1F2D816-639B-4372-B7EC-0E3884CA00A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking as regular ol=92 wg member (I took the ietf off the cc list - I intended this as a sidr = discussion, not an ietf discussion.) On May 11, 2016, at 9:08 AM, Brian Haberman = wrote: > Hi Tom, > Thanks for the in-depth review and your efforts in creating = another > implementation of this draft. Responses to your comments are below... >=20 > On 4/28/16 6:54 PM, Tom Harrison wrote: >> Section 5 requires that an EE certificate be used for the signing of >> the RPSL object. An EE certificate must contain an SIA extension = that >> points to an RPKI signed object (RFC 6487 [4.8.8.2]). The draft does >> not define a profile for a new type of object, or specify an existing >> one that may be used instead. There are a number of ways to deal = with >> this: for example, by defining a new profile and changing the >> signature URL to suit, or by amending RFC 6487 such that object >> pointers in EE certificates are optional. >=20 > 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. Given the > single-use nature of the key-pair (section 3.2, point #1), omitting = the > SIA is straightforward. >=20 wrt Tom=92s comment: It is certainly the case that currently existing EE certificates in the = RPKI appear in RPKI Signed Objects (i.e. instances of RFC6488) - = manifests, ghostbuster records, ROAs. But these aren=92t the only = possible use of EE certificates - the architecture RFC6480 mentions that = there might be other uses of EE certificates. And it is certainly the case that there=92s been no intent in this work = to put signed RPSL objects into the RPKI repositories. wrt Brian=92s suggestion: A similar example: The router certificates draft also omits the SIA = field for router EE certificates - probably for similar reasons. On May 11, 2016, at 12:56 PM, Brian Haberman = wrote: > Hi Randy, >=20 > 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. >>=20 >> perhaps you might also include your reasoning for this seemingly odd >> choice. >=20 > 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. =93A small matter of programming=94 - an RPSL database operator could = find a way to format an rsync URL so that it could be translated on = receipt to a database object retrieval. ( :-) ? ) A new type of EE cert does sound cleaner. It puts the burden on the = RPKI implementer rather than the RPSL database operators, of course. I = am not an implementer nor operator. =97Sandy, speaking as regular ol=92 working group member --Apple-Mail=_A1F2D816-639B-4372-B7EC-0E3884CA00A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXM4JnAAoJEHplpQeet0IZoJQP+gNod/R8p6Vqz/KpXU17J+Fe OJZBUDJMA4gmETsUj6DS1T8kFKkbcMucwCKjXaytZZ4dcc3+zOyI7swV05l0uqFv MGsMl05xQi3jx1r1cEKQbSJVrLNy7gcPeX9V1etZfzsb3Si88N1ucoLdkFWpUwYa V1bsZtYwa4z2Z76RwsSkxuidXu3FNuE4yHKjy8eOAnn3YucBdTXLSS41R10p6RIe qd12JX63UR7ZqvgL/taL52ruzdbtDg/eT7li9AzGKpz2QzU/EpGpVQKVcmfXF8KQ jgUfcBhjB4e2DK9NbIb7xvtJTvDszB0ix37/GNvLUMtkAmXiDyOj/O7WPllHaCin 5wdQkZHF6fw1kO6diMfx/lSnFkykyH0ydJDNoWrz1DibVAYWzqR9aJN9IocYqetn zcDJI502lTfrNAmL5o3ioXtahmxJ6UB16Z2BdlWILsAjjIdBSQfXhi9fLc22EuU9 8MtJszw87uwI43DUvvODZdxy62Tb3i33LEBEMAi1ZlNGrf0Zrg/y7HJ1JULmdWLM 2k7h0I8d+9TXXClAKD8IdN4MbkoNkoea2CPFVh4AfRiyIi1IqXCzIVdmCEGSwrFp Hpnn3a5CFJM/us4k4UCKvz0q39qwhs5SoPc3ArXF/SCkRvDTmwVAdGW60wH2w4tP 8yUwLoDEl0TX/91iWx5X =kTMK -----END PGP SIGNATURE----- --Apple-Mail=_A1F2D816-639B-4372-B7EC-0E3884CA00A6-- From nobody Wed May 11 12:09:59 2016 Return-Path: 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 2FA0112D581; Wed, 11 May 2016 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 js4bgUFkrwU8; Wed, 11 May 2016 12:09:51 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF9312D595; Wed, 11 May 2016 12:09:51 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8203628B003D; Wed, 11 May 2016 15:09:50 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 77DCE1F8055; Wed, 11 May 2016 15:09:50 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_265FCDC6-D8E9-4BC8-80DE-959713344E6D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <57332EDB.9090609@innovationslab.net> Date: Wed, 11 May 2016 15:09:50 -0400 Message-Id: <3BF5F229-FC96-403E-826E-EA0E48E2DDBE@tislabs.com> References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, ietf@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, Sandra Murphy Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:09:54 -0000 --Apple-Mail=_265FCDC6-D8E9-4BC8-80DE-959713344E6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 speaking as one of the wg co-chairs On May 11, 2016, at 9:08 AM, Brian Haberman = wrote: > Hi Tom, > Thanks for the in-depth review and your efforts in creating = another > implementation of this draft. Responses to your comments are below... >=20 > On 4/28/16 6:54 PM, Tom Harrison wrote: >> Section 5 requires that an EE certificate be used for the signing of >> the RPSL object. An EE certificate must contain an SIA extension = that >> points to an RPKI signed object (RFC 6487 [4.8.8.2]). The draft does >> not define a profile for a new type of object, or specify an existing >> one that may be used instead. There are a number of ways to deal = with >> this: for example, by defining a new profile and changing the >> signature URL to suit, or by amending RFC 6487 such that object >> pointers in EE certificates are optional. >=20 > 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. Given the > single-use nature of the key-pair (section 3.2, point #1), omitting = the > SIA is straightforward. >=20 Speaking as one of the wg co chairs: You are suggesting much the same as draft-ietf-sidr-bgpsec-pki-profiles = - defining a new EE cert profile. This draft would have to say that it is updating RFC6485(bis). Which means making clear what the additions/modification/deletions are. So that implementations know how to interpret these new certs when they = find them in some repository, it must be possible to distinguish these = new EE certs from other EE certs. Etc. And the wg would have to agree on the changes. =97Sandy, speaking as one of the wg co-chairs --Apple-Mail=_265FCDC6-D8E9-4BC8-80DE-959713344E6D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXM4N+AAoJEHplpQeet0IZVT0P/1K100m7nwWpsieZSyEIMFsj jHtAtz8O/HcNg0X/28Y2zbAUiqByUxUabf2HLaB1n9rEQQQKUrwNqz8A65tCaQ3d RozyAfAWIOKegBMSgPuQeBimuJ8qRtSLSBrfvhbbyowDY+1CDscFOG0rXozXQTjf 0tPd7oqWKT0YvUeDRU3AXQWwSTRsfGOh55gw2VjXwsqrOEGAGMfOj9X+hiKljz56 hZqCkcBFB4zTFt/JkLK1S0cwIF3hqA2Oe6mrLIPSDJxWeSynoFfrlH+aVvyRNvfz iYfnkQOpMJitgXAcn+SHPhm2QU4Op4dn2B+azVrEYlJKj77mqEPL1JxxIS+el8zu LuhlIZU0BpSpCp9C+AVx5YotjeXB8dyvBktU6sAvSj8KiHVG/pzCTpzwEDg2aaKR 0OyCoFhUUAik7z8F/AiADWC5Yf7VgheYZrk0Bql84utMOX6tp/XFZA3rzAX8bqLD /+2LJ+uE0uFI4c5SeGbsd/Y0XmD4qt8MWMGRHgn9Ll1BDI9ggsombCN9acuDO9Yu 67X6hmmteNO22onswFNgO3M8KfJmiH32tZnY/cwYbkgdFBwaWp2kl79ViLxI/S89 arirJnh/nKZtQlHOqbgrFsYTsIZwU85VX9SEAb7Hl2mJqIvzBFj66bPJrZiXPmKy Db0Gv3RjX40bV83y/hvU =e38B -----END PGP SIGNATURE----- --Apple-Mail=_265FCDC6-D8E9-4BC8-80DE-959713344E6D-- From nobody Thu May 12 04:22:51 2016 Return-Path: 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 D2AB812D950 for ; Thu, 12 May 2016 04:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 UzEIbYeCrPr5 for ; Thu, 12 May 2016 04:22:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F5612D948 for ; Thu, 12 May 2016 04:22:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b0oha-0006ol-EG; Thu, 12 May 2016 11:22:46 +0000 Date: Thu, 12 May 2016 13:22:45 +0200 Message-ID: From: Randy Bush To: Brian Haberman In-Reply-To: <57336455.1040508@innovationslab.net> References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> <57336455.1040508@innovationslab.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 11:22:50 -0000 >>> 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? randy From nobody Thu May 12 04:29:43 2016 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ) 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 In-Reply-To: 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> <57336455.1040508@innovationslab.net> To: Randy Bush 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: Cc: sidr wg list Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 11:29:42 -0000 > On 12 May 2016, at 13:22, Randy Bush wrote: >=20 >>>> 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. >>>=20 >>> this is gonna be really simple; no complications at all i am sure. >>>=20 >>> btw, was this a consensus of the wg? >>=20 >> 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. >=20 > 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. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu May 12 04:34:05 2016 Return-Path: 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 C3EB512D97C for ; Thu, 12 May 2016 04:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 eI7hhQF3hgl9 for ; Thu, 12 May 2016 04:34:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E41B12D979 for ; Thu, 12 May 2016 04:34:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b0osQ-0006qu-27; Thu, 12 May 2016 11:33:58 +0000 Date: Thu, 12 May 2016 13:33:57 +0200 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: <9A121B82-7C91-4A5E-A645-8A11C0DE647F@ripe.net> References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> <57336455.1040508@innovationslab.net> <9A121B82-7C91-4A5E-A645-8A11C0DE647F@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 11:34:04 -0000 > 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. then we have misplaced this whole discussion. it is really about using rpki keys to sign rpsl data willy-nilly, as opposed to using the rpki infrastructure. the rpki-based origin validation and bgpsec models specifically do not authenticate the authority of an AS. the AS does that by announcing. i happen to be in the building having post lunch coffee. wanna chat face to face? bring clue bat. randy From nobody Thu May 12 05:11:56 2016 Return-Path: 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 D2A2512D993; Thu, 12 May 2016 05:11:55 -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 nXGJHxxXK8Ub; Thu, 12 May 2016 05:11:49 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F97612D9BA; Thu, 12 May 2016 05:11:20 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by cyteen.hactrn.net (Postfix) with ESMTPS id B03EB7C02; Thu, 12 May 2016 12:11:18 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 14C1A3F6370D; Thu, 12 May 2016 08:11:30 -0400 (EDT) Date: Thu, 12 May 2016 08:11:29 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <6CD64C8F-F0AA-4042-B974-056F06CE5E0A@tislabs.com> References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> <6CD64C8F-F0AA-4042-B974-056F06CE5E0A@tislabs.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160512121130.14C1A3F6370D@minas-ithil.hactrn.net> Archived-At: Cc: sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 12:11:56 -0000 At Wed, 11 May 2016 15:04:58 -0400, Sandra Murphy wrote: ... > A new type of EE cert does sound cleaner. It puts the burden on the RPKI implementer rather than the RPSL database operators, of course. We already have precedent and mechanism for adding application-specific EE certificates: assign a new EKU OID, write a profile, make sure that the profile requires the new EKU and specifies all deviations from the base certificate profile. This is what we did with router certificates. As with router certificates, this means that RP code that doesn't know about the new flavor of EE certificates won't allow them. This is by design: we don't accept RPKI objects with unknown semantics. From nobody Fri May 13 03:02:21 2016 Return-Path: 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 E20D412B032; Fri, 13 May 2016 03:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 fPGs-YLabTi3; Fri, 13 May 2016 03:02:13 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4B812B020; Fri, 13 May 2016 03:02:13 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B278D28B003D; Fri, 13 May 2016 06:02:12 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 78FB61F8055; Fri, 13 May 2016 06:02:12 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_18528ACD-0F31-47DD-9401-9979DEC2F47B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <3BF5F229-FC96-403E-826E-EA0E48E2DDBE@tislabs.com> Date: Fri, 13 May 2016 06:02:11 -0400 Message-Id: References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> <3BF5F229-FC96-403E-826E-EA0E48E2DDBE@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr chairs , The IETF , draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 10:02:16 -0000 --Apple-Mail=_18528ACD-0F31-47DD-9401-9979DEC2F47B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92ve made an error in reference. Going back through to correct. On May 11, 2016, at 3:09 PM, Sandra Murphy wrote: >=20 > You are suggesting much the same as = draft-ietf-sidr-bgpsec-pki-profiles - defining a new EE cert profile. >=20 > This draft would have to say that it is updating RFC6485(bis). >=20 RFC6485 -> RFC6487. RFC6485 is about algorithms. RFC6487 is the document about RPKI = certificates. Sorry for the confusion. =97Sandy --Apple-Mail=_18528ACD-0F31-47DD-9401-9979DEC2F47B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXNaYjAAoJEHplpQeet0IZx20QAIcsj5PrzsudF2eNBQ6mA4tV VUpAcg0mxsdvGpEnUbrPUpukQr0w/9T9DbBLZs7M1vL+8Ft4EHBeKEDrGGstxaW9 y3fnZWbqjoU+w+eJ92JP/nS4GqP6ceisikJwmkvtsbONiCm1AmLEADq/EyvxI47r O2GUmftZs4clHLhz+F/4IRLPuEQfPT67+K+4Pm67sGqFv9JGa8AmY/Hf4LUzJOqp ImPuImkpi7/Awe5L5QeSIDfoIGRQsuetCiZCErASF2rE4E5qsy1m52X2aMuzgkik EMOR9tCak7kkSH4hN76O/3F0z7fxpzJaADs8kGNsj5sXN7ONjQ31x38g7hhE/96j eV1Pxf132mnPhuTrWZp6+Fq6yrKjzd/Cyni+BCzrl2B3DD2SZSFpX4GD22Co+pvr v1DKdI+zpLZLC3yrkQuIomqEVq5+SWGaBIuuEvFlHNKzHwnFcY49JQjCeI9bJoGF Q6YZaTpFvTN1vPJbExb4nbutYxlwZCr3NIkzsr/0l0cs4mnF0WeCs6BG1W8A3sMa kV+YgJSn7eq9n+v+TIVABYfcr4jQxB2xSzdxhNciID54XPNCykDEHg7DXgxzBV8F a6ME7eL8lfgWKL7N4cX1ICVxfcqMko2mHnu+FuYapHtOLniCnK/g4m0iif/e6BRz AztBQQ0N2twzWy92CfT2 =hKer -----END PGP SIGNATURE----- --Apple-Mail=_18528ACD-0F31-47DD-9401-9979DEC2F47B-- From nobody Mon May 16 06:06:45 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9D12D68F; Mon, 16 May 2016 06:06:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516130642.16756.59579.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 06:06:42 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 13:06:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Securing RPSL Objects with RPKI Signatures Authors : Robert Kisteleki Brian Haberman Filename : draft-ietf-sidr-rpsl-sig-11.txt Pages : 15 Date : 2016-05-16 Abstract: This document describes a method to allow parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have Routing Policy System Security-based authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFC 2622 and RFC 4012 to add the signature attribute to supported RPSL objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpsl-sig-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 16 11:45:16 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8B412D92C; Mon, 16 May 2016 11:45:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516184515.16709.44619.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 11:45:15 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sandy@tislabs.com Subject: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 18:45:15 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-rpsl-sig-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a generally a well written document and I don't object to its publication. However I have several minor but important points which should be easy to address: In Section 2.1: Reference to the certificate corresponding to the private key used to sign this object (field "c"). The value of this field MUST be a URL of type "rsync" or "http(s)" You need to have Normative references for the corresponding URI RFCs: RFC 5781 for rsync URIs and RFC 7230 for http/https URIs. that points to a specific resource certificate in an RPKI repository [RFC6481]. Any non URL-safe characters (including semicolon ";" and plus "+") must be URL encoded. This really need a Normative reference to RFC 3986. The signature itself (field "b"). This MUST be the last field in the list. The signature is the output of the signature algorithm using the appropriate private key and the calculated hash value of the object as inputs. The value of this field is the digital signature in base64 encoding [RFC4648]. As RFC 4648 specifies 2 base64 alphabets, you need to include section number. I think you meant Section 4 (and not Section 5). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2.1: Time of signing (field "t"). The format of the value of this field MUST be in the Internet Date/Time format [RFC3339]. All times MUST be converted to Universal Coordinated Time (UTC) To be pedantic, you should clarify that you mean the date-time ABNF production with the timezone always being "Z". In 3.1, inside numbered list (item 3): * Converting all line endings to a single blank space. Please include ASCII code for space, because " " is not very helpful, especially considering that there are other Unicode space characters which are not visually distinguishable. The same issue elsewhere in this section. From nobody Tue May 17 07:22:23 2016 Return-Path: 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 19B1712D64A; Tue, 17 May 2016 07:22:18 -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 2jIDo483aiTc; Tue, 17 May 2016 07:22:16 -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 675D012D650; Tue, 17 May 2016 07:22:16 -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 48E698810D; Tue, 17 May 2016 07:22:16 -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 971B4328081A; Tue, 17 May 2016 07:22:15 -0700 (PDT) To: Alexey Melnikov , The IESG References: <20160516184515.16709.44619.idtracker@ietfa.amsl.com> From: Brian Haberman Message-ID: Date: Tue, 17 May 2016 10:22:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160516184515.16709.44619.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="239v6NMp7VoH91kOscQo7Ug7qCCwI24mx" Archived-At: Cc: sandy@tislabs.com, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 14:22:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --239v6NMp7VoH91kOscQo7Ug7qCCwI24mx Content-Type: multipart/mixed; boundary="rtOG3RR4k4BjINQSEiOEaH8I80B05X1E7" From: Brian Haberman To: Alexey Melnikov , The IESG Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sandy@tislabs.com Message-ID: Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160516184515.16709.44619.idtracker@ietfa.amsl.com> In-Reply-To: <20160516184515.16709.44619.idtracker@ietfa.amsl.com> --rtOG3RR4k4BjINQSEiOEaH8I80B05X1E7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Alexey, Thanks for the feedback. I have placed responses in-line... On 5/16/16 2:45 PM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-sidr-rpsl-sig-11: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a generally a well written document and I don't object to its > publication. However I have several minor but important points which > should be easy to address: >=20 > In Section 2.1: >=20 > Reference to the certificate corresponding to the private key used to= > sign this object (field "c"). The value of this field MUST be a URL of > type "rsync" or "http(s)" >=20 > You need to have Normative references for the corresponding URI RFCs: R= FC > 5781 for rsync URIs and RFC 7230 for http/https URIs. >=20 > that points to a specific resource certificate in an RPKI repository > [RFC6481]. Any non URL-safe characters (including semicolon ";" and plu= s > "+") must be URL encoded. >=20 > This really need a Normative reference to RFC 3986. >=20 Both of the above sound reasonable. The resulting text will be: o Reference to the certificate corresponding to the private key used to sign this object (field "c"). The value of this field MUST be a URL of type "rsync" [RFC5781] or "http(s)" [RFC7230] that points to a specific resource certificate in an RPKI repository [RFC6481]. Any non URL-safe characters (including semicolon ";" and plus "+") must be URL encoded [RFC3986]. >=20 > The signature itself (field "b"). This MUST be the last field in the > list. The signature is the output of the signature algorithm using the > appropriate private key and the calculated hash value of the object as > inputs. The value of this field is the digital signature in base64 > encoding [RFC4648]. >=20 > As RFC 4648 specifies 2 base64 alphabets, you need to include section > number. I think you meant Section 4 (and not Section 5). Yes. I will include Section 4 in the reference to 4648. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In Section 2.1: >=20 > Time of signing (field "t"). The format of the value of this field MU= ST > be in the Internet Date/Time format [RFC3339]. All times MUST be > converted to Universal Coordinated Time (UTC) >=20 > To be pedantic, you should clarify that you mean the date-time ABNF > production with the timezone always being "Z". Done. >=20 > In 3.1, inside numbered list (item 3): >=20 > * Converting all line endings to a single blank space. I will note that it will be ASCII code 32. I will also add ASCII codes for newline and tabs mentioned elsewhere. The above changes are queued up in a -12 version. Regards, Brian --rtOG3RR4k4BjINQSEiOEaH8I80B05X1E7-- --239v6NMp7VoH91kOscQo7Ug7qCCwI24mx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXOykWAAoJEBOZRqCi7goqSuAH/R6nN48W9ZUmezQHRXBmEHaM MzMTwykEGZjnptvy85+0Q9ALGjd3JwT5Cm+5Ukty8oH7BIjXhOfOt2F3bsKpmiF5 Oe7EYGtN6LyMym7k+TX9FwyMUDANejNkPJFFXIcP9xV9Rbngk3G2VbS5ZPiQg7LN fuJylUjmdRUs62RUgpUwuTiZZfxwwDAkQ66y2jvCWprllT8puBwGLkAp0Z6chigo 62kH4msUigs7RVdQsPB2x920aEzOmEA3s8PIE8jj/CIociVRcb64b1rzP5laJ5Ze 3jygj83ZZt0JqRnz8xrGvbQFRkOP2HcTKjfECtVn1+O9eYyrO+iBAYEAghUcv5E= =i/pe -----END PGP SIGNATURE----- --239v6NMp7VoH91kOscQo7Ug7qCCwI24mx-- From nobody Tue May 17 20:37:56 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 781E412D1AC; Tue, 17 May 2016 20:37:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 20:37:54 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sandy@tislabs.com Subject: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 03:37:54 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-rpsl-sig-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for putting substantial effort into this document. I have a few discusses. I hope they can be resolved quickly. In Section 2.1. The reference to the aligned certificate which has the same private key that signed the RPSL object is mandatory, and defined by a RSYNC URL or a HTTP(S) URL. My question surrounds the "or". The architecture of RPKI (IIRC) is centered around RSYNC, and thus SIA/AIA values MUST have a RSYNC URL, and MAY have other types. By this are you leaving it to the issuing party to control the RPKI Distribution mechanisms of the Replying Party? I am quite comfortable with "or" personally, however this facet of fetching the RPSL Certificate to validate the private key usage is seemingly orthogonal to the RPKI architecture of RSYNC preferred and should be called out if 'or' is the clear intention. Or, has the consensus of the WG moved on from being wedded to RSYNC? If it is truely "or", my observation is that the use of the RPKI repository is one of convenience, and that should be called out, in fact it does appear that any valid certificate bearing RFC3779 extensions could be used to validate the digital signature associated with the RPSL object provided the relying party has trust anchor material that leads to the corresponding EE certificate and therefore private key. Is this observation correct? The Signature expiration time field ("x") currently has no time constraints, and I'm very surprised that it is optional with the text in s2.5, given that the expiration time, by my reading, could not be beyond the 'not after' time of the corresponding certificate. Can you please instruct me as to what the consensus position on this was? A criticism of many IRRs is that data becomes stale. have the signature expiration time field could aide in data freshness models and reduce load on automated import and validation of these RPSL signatures. And lastly, IRRs tend to run over the (legacy?) whois port 43 that doesn't provide channel layer security. This means that while signature provide a means of detecting modification it may not stop a a MiTM event where the entire object is omitted. Do you agree? if so that might be appropriate for the Security Considerations section. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- one nit: "MUST reject the signature and threat the object as a regular" I think you mean `s/threat/treat` Misc comments: * Thank you for the very clear canonicalisation requirements! * For route6 objects, where two resource holder's signatures considered such that it might address the inability to properly sign the RPSL when one holder possesses the ASN and another possesses the prefix? (just a comment, nothing more) From nobody Wed May 18 06:08:36 2016 Return-Path: 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 D388D128E19; Wed, 18 May 2016 06:08:29 -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 jrLQnEAEqxtw; Wed, 18 May 2016 06:08:27 -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 B87D612D0BC; Wed, 18 May 2016 06:08:21 -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 8A768880E7; Wed, 18 May 2016 06:08:21 -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 B4A1A328081A; Wed, 18 May 2016 06:08:20 -0700 (PDT) To: Terry Manderson , The IESG References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> From: Brian Haberman Message-ID: Date: Wed, 18 May 2016 09:08:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fgjMLg424ItRrcU13lH5WA5JdjlMn5gx8" Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 13:08:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fgjMLg424ItRrcU13lH5WA5JdjlMn5gx8 Content-Type: multipart/mixed; boundary="CF4aDi0Nd6AC3lgxJXiksioL7Xi3FK2aN" From: Brian Haberman To: Terry Manderson , The IESG Cc: draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" , aretana@cisco.com, sidr-chairs@ietf.org, sidr@ietf.org Message-ID: Subject: Re: Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> In-Reply-To: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> --CF4aDi0Nd6AC3lgxJXiksioL7Xi3FK2aN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Terry, On 5/17/16 11:37 PM, Terry Manderson wrote: > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpsl-sig-11: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for putting substantial effort into this document. >=20 > I have a few discusses. I hope they can be resolved quickly. >=20 > In Section 2.1. The reference to the aligned certificate which has the= > same private key that signed the RPSL object is mandatory, and defined = by > a RSYNC URL or a HTTP(S) URL. My question surrounds the "or". The > architecture of RPKI (IIRC) is centered around RSYNC, and thus SIA/AIA > values MUST have a RSYNC URL, and MAY have other types. By this are you= > leaving it to the issuing party to control the RPKI Distribution > mechanisms of the Replying Party? I am quite comfortable with "or" > personally, however this facet of fetching the RPSL Certificate to > validate the private key usage is seemingly orthogonal to the RPKI > architecture of RSYNC preferred and should be called out if 'or' is the= > clear intention. Or, has the consensus of the WG moved on from being > wedded to RSYNC? I am not aware of the WG moving away from their rsync leanings... >=20 > If it is truely "or", my observation is that the use of the RPKI > repository is one of convenience, and that should be called out, in fa= ct > it does appear that any valid certificate bearing RFC3779 extensions > could be used to validate the digital signature associated with the RPS= L > object provided the relying party has trust anchor material that leads = to > the corresponding EE certificate and therefore private key. Is this > observation correct? You are correct that the use of the RPKI repository is one of convenience. My original implementation of this approach used non-RPKI certificates. I would be fine with putting a statement in the Introduction along the lines of: "While the approach outlined in this document mandates the use of the RPKI for certificate distribution, it is not dependent upon the RPKI for correct functionality. Equivalent functionality can be achieved with a more traditional certificate authority, RFC 3779 extensions within the certificates, and the appropriate trust anchor material to verify the digital signature." >=20 > The Signature expiration time field ("x") currently has no time > constraints, and I'm very surprised that it is optional with the text i= n > s2.5, given that the expiration time, by my reading, could not be beyon= d > the 'not after' time of the corresponding certificate. Can you please > instruct me as to what the consensus position on this was? A criticism = of > many IRRs is that data becomes stale. have the signature expiration tim= e > field could aide in data freshness models and reduce load on automated > import and validation of these RPSL signatures. The validity of the signature is driven by the notAfter field of the certificate described in 6487. My implementation does the validation based on notAfter regardless of what is included in the "x" field. I view "x" as a simple way for RPSL object signers to indicate the lifetime, but not the authoritative way. >=20 > And lastly, IRRs tend to run over the (legacy?) whois port 43 that > doesn't provide channel layer security. This means that while signature= > provide a means of detecting modification it may not stop a a MiTM even= t > where the entire object is omitted. Do you agree? if so that might be > appropriate for the Security Considerations section. >=20 I agree with the potential MiTM attack described, but view that as orthogonal to digital signatures providing integrity protection. This type of attack could easily occur regardless of whether objects are signed or not. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > one nit: >=20 > "MUST reject the signature and threat the object as a regular" I think > you mean `s/threat/treat` Fixed in my pending edit buffer. >=20 > Misc comments: >=20 > * Thank you for the very clear canonicalisation requirements! >=20 > * For route6 objects, where two resource holder's signatures considered= > such that it might address the inability to properly sign the RPSL when= > one holder possesses the ASN and another possesses the prefix? (just a > comment, nothing more) >=20 Not sure I can parse the above unless s/where/were/... If so, that was originally in the document prior to -09, but the consensus of the WG was to remove multiple signature support. Regards, Brian --CF4aDi0Nd6AC3lgxJXiksioL7Xi3FK2aN-- --fgjMLg424ItRrcU13lH5WA5JdjlMn5gx8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXPGlDAAoJEBOZRqCi7goqGW8IAL8ZAjDDjP2vPUoZwfjuMdjm kAZg6pEFP7+SGKIGmiOaym2Y2DK26cVVCSapfj293ciz0h/3izkpWmlqFU2OGpzC s62VEdrMkpR9y82d6gcgCMv9hByALTzf9e/kLjWSy6PBVVO4Ux3tH75vkd5x7P3U 1ZOh2TaEDDq3/QsyLbNzFSQTHBY47DDj2kfnAwfgP/b37xZPvS96y1hzFJc1dn1t GlRfhEknDys5yP6uyzz3OwcTXMqsTw0cg7X5Hh5UpIjowa3VFi/ZPYEI0NWlG4Uv tdJJTHdDPlMU1Iqb/vnogum2MX0DzgWP29wjQsctTXZRM9Nnw6n8GlOYUq0weYk= =uSD+ -----END PGP SIGNATURE----- --fgjMLg424ItRrcU13lH5WA5JdjlMn5gx8-- From nobody Wed May 18 07:32:52 2016 Return-Path: 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 8B3F312D520; Wed, 18 May 2016 07:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 XrEGtbFoR3lD; Wed, 18 May 2016 07:32:49 -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 BDB8012D515; Wed, 18 May 2016 07:32:49 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1b32Wg-0004kd-UG; Wed, 18 May 2016 16:32:44 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-125.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1b32Wg-0005Wn-PE; Wed, 18 May 2016 16:32:42 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Wed, 18 May 2016 16:32:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> To: Brian Haberman X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ---------- X-RIPE-Spam-Report: Spam Total Points: -10.8 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 -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719597cea4b71085b338f53798a69ee467a Archived-At: Cc: draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org, The IESG , "Sandra L. Murphy" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:32:51 -0000 Hi, > On 18 May 2016, at 15:08, Brian Haberman = wrote: >=20 > Hi Terry, >=20 > On 5/17/16 11:37 PM, Terry Manderson wrote: >> Terry Manderson has entered the following ballot position for >> draft-ietf-sidr-rpsl-sig-11: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thank you for putting substantial effort into this document. >>=20 >> I have a few discusses. I hope they can be resolved quickly. >>=20 >> In Section 2.1. The reference to the aligned certificate which has = the >> same private key that signed the RPSL object is mandatory, and = defined by >> a RSYNC URL or a HTTP(S) URL. My question surrounds the "or". The >> architecture of RPKI (IIRC) is centered around RSYNC, and thus = SIA/AIA >> values MUST have a RSYNC URL, and MAY have other types. By this are = you >> leaving it to the issuing party to control the RPKI Distribution >> mechanisms of the Replying Party? I am quite comfortable with "or" >> personally, however this facet of fetching the RPSL Certificate to >> validate the private key usage is seemingly orthogonal to the RPKI >> architecture of RSYNC preferred and should be called out if 'or' is = the >> clear intention. Or, has the consensus of the WG moved on from being >> wedded to RSYNC? >=20 > I am not aware of the WG moving away from their rsync leanings... My take on this: for the moment I would stick to rsync as it's required = and EE certificates appearing in the rsync repository, and leave out = http(s). Work is being done on RRDP. In time this may replace rsync altogether. = This is speculation at this time, but.. one way to look at this could be = to have AKI and a reference to a TA or an RRDP publication point = (notification file) where the signing EE certificate is supposed to be = found. Just shooting from the hip here, bottom line: this is a = discussion and decision for a later time, and is probably best addressed = in a -bis. Tim From nobody Wed May 18 08:03:12 2016 Return-Path: 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 17EF812D57D; Wed, 18 May 2016 08:03:05 -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 UbKTn8B74vrT; Wed, 18 May 2016 08:03:03 -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 20AA612D139; Wed, 18 May 2016 08:03:03 -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 DFE6F880E4; Wed, 18 May 2016 08:03:02 -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 28E85328081A; Wed, 18 May 2016 08:03:02 -0700 (PDT) To: Tim Bruijnzeels References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> From: Brian Haberman Message-ID: Date: Wed, 18 May 2016 11:02:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CmAaRo46bfs4ox986wWNKcab2LjhJofD3" Archived-At: Cc: draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org, The IESG , "Sandra L. Murphy" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:03:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CmAaRo46bfs4ox986wWNKcab2LjhJofD3 Content-Type: multipart/mixed; boundary="pTDLDsUREPVRAiB0e5BTXEDV6lbxucnQp" From: Brian Haberman To: Tim Bruijnzeels Cc: Terry Manderson , The IESG , sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" Message-ID: Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> In-Reply-To: <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> --pTDLDsUREPVRAiB0e5BTXEDV6lbxucnQp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Tim, On 5/18/16 10:32 AM, Tim Bruijnzeels wrote: > Hi, >=20 >> On 18 May 2016, at 15:08, Brian Haberman >> wrote: >>=20 >> Hi Terry, >>=20 >> On 5/17/16 11:37 PM, Terry Manderson wrote: >>> Terry Manderson has entered the following ballot position for=20 >>> draft-ietf-sidr-rpsl-sig-11: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to >>> all email addresses included in the To and CC lines. (Feel free >>> to cut this introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>> more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found >>> here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------= - >>> >>>=20 DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> >>>=20 Thank you for putting substantial effort into this document. >>>=20 >>> I have a few discusses. I hope they can be resolved quickly. >>>=20 >>> In Section 2.1. The reference to the aligned certificate which >>> has the same private key that signed the RPSL object is >>> mandatory, and defined by a RSYNC URL or a HTTP(S) URL. My >>> question surrounds the "or". The architecture of RPKI (IIRC) is >>> centered around RSYNC, and thus SIA/AIA values MUST have a RSYNC >>> URL, and MAY have other types. By this are you leaving it to the >>> issuing party to control the RPKI Distribution mechanisms of the >>> Replying Party? I am quite comfortable with "or" personally, >>> however this facet of fetching the RPSL Certificate to validate >>> the private key usage is seemingly orthogonal to the RPKI=20 >>> architecture of RSYNC preferred and should be called out if 'or' >>> is the clear intention. Or, has the consensus of the WG moved on >>> from being wedded to RSYNC? >>=20 >> I am not aware of the WG moving away from their rsync leanings... >=20 > My take on this: for the moment I would stick to rsync as it's > required and EE certificates appearing in the rsync repository, and > leave out http(s). >=20 If the consensus is to remove mention of an http(s) URI, I can live with that. The current state of affairs within the SIDR documentation is such that only an rsync URI will be feasible in the near future. I don't believe that the mention of an http(s) URI in this context affects that one way or the other. Regards, Brian --pTDLDsUREPVRAiB0e5BTXEDV6lbxucnQp-- --CmAaRo46bfs4ox986wWNKcab2LjhJofD3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXPIQjAAoJEBOZRqCi7goqJrAIAKkTfPcNlZqkqJY8g3BV1s6M h+Fb98+cJTxuzaMWbAt5YVuJYHMxYtnpIuzke5mEJt40yI6fUWjqnKkQML5dwnyI jweAuNptNR2lodcS4ioiQu08bhvQ8zS4dVDNtF2SoMd1wgwqAD6Kkos4tY5svIJb nvZpyCSIxvhlIMHXG7Q7eCvB9DcP2M1Lceb1xE0o3rpr2Zmi1j0XI+r2lMScaNHv 1VJ1HA4yu9LhJtv4tGQyKUIW4ddMjy2YGS/2pGTK7WCGx6d0GMWsrcc8VwerxWKX 1KUo4DGADumC/bKKO+k0UW2aKOHUHvnt+Jke8WRJIv54GsPoFjN/BivTCxNGDlI= =fuoC -----END PGP SIGNATURE----- --CmAaRo46bfs4ox986wWNKcab2LjhJofD3-- From nobody Wed May 18 08:51:11 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A322412D113; Wed, 18 May 2016 08:51:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 08:51:09 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sandy@tislabs.com Subject: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:51:09 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-rpsl-sig-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to check one thing - this may be needed for strict compliance with RPKI thing but it seems kinda weird to also impose that here, but anyway... Is 3.2 step 1 needed? That seems like useless complexity here. If it is needed, how does the verifier check that it's really a single-use? I don't see the point TBH. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - If you keep the potential for http(s) URIs then I think more text is needed in the security considerations but it looks like you're taking that out for now so I guess that's ok. - 2.1, I don't see why it's useful to allow variation in the fields of the signature attribute e.g. why "MAY" the version not be 1st? - 2.1, "t=" and "x=" any limits on precision here? (Non-)support for fractional seconds can be a source for non-interop if not. The "All times MUST be converted to" is also actually a little ambiguous as you don't say to do that before signing;-) - 2.1, "a=" did you want a lowercase "must" there? - Are steps 2 and 3 in 3.1 order-sensitive? I think you might sometimes need to do 2 after 3, or re-do 2 maybe or else leading whitspace could be an issue. Maybe say that sometimes you need to do step 2 >1 time? - 3.1, oops, an ambiguity - in "The following steps MUST be applied in order..." does "in order" mean "in the order below" or "so as to"? I assume the latter. - 3.1: In general I think you'd be better if you pointed at specific bits of text in all the RFCs mentioned in 3.1 - it's maybe easy to get wrong otherwise, esp. if we don't yet have >1 implementation. - 3.1, step 6: names are all ASCII right? just checking - 3.2, step 1 - given 3.3 step 2, you're missing a step to "publish the cert" at the c= location as well. From nobody Wed May 18 09:06:41 2016 Return-Path: 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 02D1312D1B3; Wed, 18 May 2016 09:06:41 -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 L4mKwMN74zlI; Wed, 18 May 2016 09:06:40 -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 9A92212D1AA; Wed, 18 May 2016 09:06:38 -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 7D90B880E3; Wed, 18 May 2016 09:06:38 -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 892DC328081A; Wed, 18 May 2016 09:06:37 -0700 (PDT) To: Stephen Farrell , The IESG References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> From: Brian Haberman Message-ID: <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> Date: Wed, 18 May 2016 12:06:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RWle8pljenUKu6uMCfFF8NNlmNC9MucUd" Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:06:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RWle8pljenUKu6uMCfFF8NNlmNC9MucUd Content-Type: multipart/mixed; boundary="frhg0sQbKNO9FDPIOpplOQmJAObJ25nLW" From: Brian Haberman To: Stephen Farrell , The IESG Cc: draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" , aretana@cisco.com, sidr-chairs@ietf.org, sidr@ietf.org Message-ID: <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> Subject: Re: Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> In-Reply-To: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> --frhg0sQbKNO9FDPIOpplOQmJAObJ25nLW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Stephen, On 5/18/16 11:51 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-sidr-rpsl-sig-11: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > I'd like to check one thing - this may be needed for strict > compliance with RPKI thing but it seems kinda weird to also > impose that here, but anyway... >=20 > Is 3.2 step 1 needed? That seems like useless complexity > here. If it is needed, how does the verifier check that > it's really a single-use? I don't see the point TBH. >=20 This text was driven by the statement in RFC 6487 (Section 3) that says: The private key associated with an EE certificate is used to sign a single RPKI signed object, i.e., the EE certificate is used to validate only one object. Step 1 in 3.2 is there so that this approach follows the above directive on the use of the RPKI infrastructure/certificates. Regards, Brian --frhg0sQbKNO9FDPIOpplOQmJAObJ25nLW-- --RWle8pljenUKu6uMCfFF8NNlmNC9MucUd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXPJMKAAoJEBOZRqCi7goqQPwH/jqGc07kCD6tFda7Jyz8PwWp LaXz7THBTEE6TlMeCnFCjoIlDUpRz0KyykbGKAQKbIiQfZo2fDpsBwjAdWdZUfwH D8aFu0YsXu1TS3e6TWnYxWdjJgZOcxjWyBk4LvNNU0nC9WouqwBv++14kIJUrLuQ A7vUjt607YKlTbqdg9eUxapCYwJSLYVBKXnJHWz3muaqXEbKZxj3WaG5kKQ+XIyE qzRXcI2iPJlJ8YiQu5vaArUZGnJ5bLliy9QRVR2s1u3Mo9LJFL7t/YbDaaJHH88U bzrsbaGXJAh4C2a9ygjvhu5XyUdPR6kg2E4uX1JVimr7U5y3KdrfcgoRU3K7tKM= =Nsi0 -----END PGP SIGNATURE----- --RWle8pljenUKu6uMCfFF8NNlmNC9MucUd-- From nobody Wed May 18 09:10:00 2016 Return-Path: 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 E2C1F12D5B6; Wed, 18 May 2016 09:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 6ntG0LOnICqq; Wed, 18 May 2016 09:09:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC1912D1A8; Wed, 18 May 2016 09:09:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8E545BE2C; Wed, 18 May 2016 17:09:52 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek_VLF2Z0h8Z; Wed, 18 May 2016 17:09:52 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E283CBDF9; Wed, 18 May 2016 17:09:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463587792; bh=lO+5IkpDFYjZSaXMjjetphmUpD4RLEXLbcPlFqUmQL8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=wZGlFLgi4MLCiG2wO9Y8k8VmGeeOgA3RapMT98HcMyYKnew+Pd67AaI6dHwy+hNv8 lsMX6OOVHOrX6pBj5H1NGGUUOEbMGWB6kMAht4vk7GIlk/VCwgh7Rzndoalg2r0CXZ DYrqYUcnUNEgoLIIjj+80Io5tmhl1jHxM4fADbSg= To: Brian Haberman , The IESG References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573C93CD.4040901@cs.tcd.ie> Date: Wed, 18 May 2016 17:09:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sIgdj85i8QoXMvVu7S74MNb2eqtTK229t" Archived-At: Cc: "Sandra L. Murphy" , sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:09:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sIgdj85i8QoXMvVu7S74MNb2eqtTK229t Content-Type: multipart/mixed; boundary="hgv194Rr36TNvowXPivkOuWfGnxEDrkU3" From: Stephen Farrell To: Brian Haberman , The IESG Cc: sidr@ietf.org, aretana@cisco.com, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" Message-ID: <573C93CD.4040901@cs.tcd.ie> Subject: Re: Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> In-Reply-To: <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> --hgv194Rr36TNvowXPivkOuWfGnxEDrkU3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 18/05/16 17:06, Brian Haberman wrote: > Hiya Stephen, >=20 > On 5/18/16 11:51 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-sidr-rpsl-sig-11: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> I'd like to check one thing - this may be needed for strict >> compliance with RPKI thing but it seems kinda weird to also >> impose that here, but anyway... >> >> Is 3.2 step 1 needed? That seems like useless complexity >> here. If it is needed, how does the verifier check that >> it's really a single-use? I don't see the point TBH. >> >=20 > This text was driven by the statement in RFC 6487 (Section 3) that says= : >=20 > The private key associated with an EE certificate is used to sign a > single RPKI signed object, i.e., the EE certificate is used to > validate only one object. >=20 > Step 1 in 3.2 is there so that this approach follows the above directiv= e > on the use of the RPKI infrastructure/certificates. Well... sure. But what is the benefit here? IIRC that was something related to making more fine-grained revocation possible or something which doesn't seem that useful here since a verifier will likely already have processed stuff already or am I mixed up? If there's no benefit, it seems like that adds a bunch of CA code just for fun (or "compliance" maybe;-) Ta, S. >=20 > Regards, > Brian >=20 --hgv194Rr36TNvowXPivkOuWfGnxEDrkU3-- --sIgdj85i8QoXMvVu7S74MNb2eqtTK229t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXPJPNAAoJEC88hzaAX42iQCIIAKaEEh/SoE675C1GrJz+IcOF ILnK9Zm9ll+Wb9hh0WifyTxrUsJprpfT0xq+1aP33bdLzM9UMQXmYVcuNmrsaX1U mxNb7er8+pSOXWz/dIul9LM0XrrWPllA7NR7yZdjF6imA4e9XFw9nv3r51iv0ial HRJT8CFvnHW7/ijyILU+WrnlFq+gKlMqBRDCrc0dBGj+CTNhdO4w9z7bFQXW80HT pSaH0eJ8vy6Ld1Ly44OJNMVhikH04cgEf5bTJAahWIPD9qN+oq+P7BUjIRf7Pqox fYpqcb7b5WVi3FCHlmiAn3w+Z6/VDvKbH49zR1tyah8UPNaGFKozIP0bpUaG6CQ= =leaA -----END PGP SIGNATURE----- --sIgdj85i8QoXMvVu7S74MNb2eqtTK229t-- From nobody Wed May 18 09:20:48 2016 Return-Path: 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 650EF12D1A8; Wed, 18 May 2016 09:20:46 -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 u-khDiRTIBqA; Wed, 18 May 2016 09:20:43 -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 1BB2512D5C9; Wed, 18 May 2016 09:20:15 -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 B29AF880E3; Wed, 18 May 2016 09:20:14 -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 0F4D3328081A; Wed, 18 May 2016 09:20:13 -0700 (PDT) To: Stephen Farrell , The IESG References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> From: Brian Haberman Message-ID: <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> Date: Wed, 18 May 2016 12:20:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <573C93CD.4040901@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qrR4Abc0k3WI7h1PURoHm6jmGAlp2F1mU" Archived-At: Cc: "Sandra L. Murphy" , sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:20:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qrR4Abc0k3WI7h1PURoHm6jmGAlp2F1mU Content-Type: multipart/mixed; boundary="VeqpCamj9NlWX07qdbFG5EHn5sGLxbsid" From: Brian Haberman To: Stephen Farrell , The IESG Cc: sidr@ietf.org, aretana@cisco.com, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" Message-ID: <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> Subject: Re: Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> In-Reply-To: <573C93CD.4040901@cs.tcd.ie> --VeqpCamj9NlWX07qdbFG5EHn5sGLxbsid Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Stephen, On 5/18/16 12:09 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 18/05/16 17:06, Brian Haberman wrote: >> Hiya Stephen, >> >> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-sidr-rpsl-sig-11: Discuss >>> >>> When responding, please keep the subject line intact and reply to all= >>> email addresses included in the To and CC lines. (Feel free to cut th= is >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> >>> I'd like to check one thing - this may be needed for strict >>> compliance with RPKI thing but it seems kinda weird to also >>> impose that here, but anyway... >>> >>> Is 3.2 step 1 needed? That seems like useless complexity >>> here. If it is needed, how does the verifier check that >>> it's really a single-use? I don't see the point TBH. >>> >> >> This text was driven by the statement in RFC 6487 (Section 3) that say= s: >> >> The private key associated with an EE certificate is used to sign a= >> single RPKI signed object, i.e., the EE certificate is used to >> validate only one object. >> >> Step 1 in 3.2 is there so that this approach follows the above directi= ve >> on the use of the RPKI infrastructure/certificates. >=20 > Well... sure. But what is the benefit here? IIRC that was I *think* the benefit is supposed to be compliance with the RPKI approach= =2E.. > something related to making more fine-grained revocation > possible or something which doesn't seem that useful here > since a verifier will likely already have processed stuff > already or am I mixed up? I don't think you are mixed up, but I will let others in SIDR chime in...= >=20 > If there's no benefit, it seems like that adds a bunch of > CA code just for fun (or "compliance" maybe;-) I could very easily see dropping step 1 from 3.2 and simply augmenting the intro sentence with something about certs/keys generated per 3487. Regards, Brian --VeqpCamj9NlWX07qdbFG5EHn5sGLxbsid-- --qrR4Abc0k3WI7h1PURoHm6jmGAlp2F1mU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXPJY7AAoJEBOZRqCi7goqJOoIAJvO78SYeZ4oaf2SrW6cON9W d9ezUOuKBsGS1BFcKeP6N41vzaKKNu/1Cfy4Y55SdmFZ92A7ysh3fOy5HE513NA2 O7NjqwNNt2PEvLSxgWsvv+m4mcwiyXiBGlgBRM/Iiwc+QrWbTIy6LCs4D+OusdaI 25wlwoWwU6p5D3+5i2YJux0/z3Ne6VktLIvbqCjvflkf/MW2j5xR4FyZt6slQx3e aaRoLeRi5HPAG4b4OT0Q1ioX/Iqif3IIKuEV81vIBEtVmsJcIY4/IGOIWLsyoQc/ uwXRh3TP9C13ZDCCHzt/M4P/Sm+ucBMfdQ2HTZ/r6zLkP6FJM1yHwbK5vChNRJo= =mxmX -----END PGP SIGNATURE----- --qrR4Abc0k3WI7h1PURoHm6jmGAlp2F1mU-- From nobody Wed May 18 09:32:14 2016 Return-Path: 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 A593B12D5CC; Wed, 18 May 2016 09:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 R4CVaZojMej5; Wed, 18 May 2016 09:32:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F04012D1AA; Wed, 18 May 2016 09:32:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BECFFBE2C; Wed, 18 May 2016 17:32:09 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udyUo65eMuG4; Wed, 18 May 2016 17:32:09 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 24747BDF9; Wed, 18 May 2016 17:32:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463589129; bh=hNj1prQFJO+uvtlR+EhO4cNTTejLjR1bJPQxPKDt1Us=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=37eREEzipGXdNAfwBwqgFNLSF6O9VFXireH4VH4zp3yJf+vDDndWNUrEn2bAhHDVm b9QdfO7MvKp8n03T0aNUENMvaS353zfVSaV6gRGU4Sbcx+s3DR6mAlscAKyjKDrUSa hP/VjdCF5fkjSuTQ9ryRpZIMX9rDUC4sGsWvLaXc= To: Brian Haberman , The IESG References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573C9906.4000506@cs.tcd.ie> Date: Wed, 18 May 2016 17:32:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NrwwJDUhLWqBVswDBUg5JcN440tLWPltn" Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:32:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NrwwJDUhLWqBVswDBUg5JcN440tLWPltn Content-Type: multipart/mixed; boundary="AMnrpm9HTp49uncGRCi2xQueBWKOuKEes" From: Stephen Farrell To: Brian Haberman , The IESG Cc: "Sandra L. Murphy" , aretana@cisco.com, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Message-ID: <573C9906.4000506@cs.tcd.ie> Subject: Re: Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> In-Reply-To: <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> --AMnrpm9HTp49uncGRCi2xQueBWKOuKEes Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable goto bottom:-) On 18/05/16 17:20, Brian Haberman wrote: > Hiya Stephen, >=20 > On 5/18/16 12:09 PM, Stephen Farrell wrote: >> >> Hiya, >> >> On 18/05/16 17:06, Brian Haberman wrote: >>> Hiya Stephen, >>> >>> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-sidr-rpsl-sig-11: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to al= l >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= =2Ehtml >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> I'd like to check one thing - this may be needed for strict >>>> compliance with RPKI thing but it seems kinda weird to also >>>> impose that here, but anyway... >>>> >>>> Is 3.2 step 1 needed? That seems like useless complexity >>>> here. If it is needed, how does the verifier check that >>>> it's really a single-use? I don't see the point TBH. >>>> >>> >>> This text was driven by the statement in RFC 6487 (Section 3) that sa= ys: >>> >>> The private key associated with an EE certificate is used to sign = a >>> single RPKI signed object, i.e., the EE certificate is used to >>> validate only one object. >>> >>> Step 1 in 3.2 is there so that this approach follows the above direct= ive >>> on the use of the RPKI infrastructure/certificates. >> >> Well... sure. But what is the benefit here? IIRC that was >=20 > I *think* the benefit is supposed to be compliance with the RPKI approa= ch... >=20 >> something related to making more fine-grained revocation >> possible or something which doesn't seem that useful here >> since a verifier will likely already have processed stuff >> already or am I mixed up? >=20 > I don't think you are mixed up, but I will let others in SIDR chime in.= =2E. Yeah, be good if someone could justify doing that. Maybe there's a good reason, though I'm not seeing it. >=20 >> >> If there's no benefit, it seems like that adds a bunch of >> CA code just for fun (or "compliance" maybe;-) >=20 > I could very easily see dropping step 1 from 3.2 and simply augmenting > the intro sentence with something about certs/keys generated per 3487. My guess is that that'd lead signing implementers to not generate new and possibly useless certs. I guess I'd be ok with that but it seems a bit unfair of us to be sorta kinda not telling 'em that they ought have the code for that. (The verifier doesn't know/care in this case afaics, though of course that means that the once-only aspect is also a bit "pretendy" too I suppose.) Anyway, yeah, maybe having someone more up to speed on sidr than I say why this makes sense here is the best next step so that we don't muck up or take the pretendy route? Cheers, S. >=20 > Regards, > Brian >=20 >=20 --AMnrpm9HTp49uncGRCi2xQueBWKOuKEes-- --NrwwJDUhLWqBVswDBUg5JcN440tLWPltn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXPJkHAAoJEC88hzaAX42ik0gIAINhKC9JFEjUO3mlpOEEv08Y UvBk3AKYBHHhb2J4ynWo4NRix/mpyPXNRHhu183SZei+34OgZ07hFWHBJPzh7Tmw tsFLLyYvZuNyLLlhZsSV9aRFscofYDLCrEd+jkMDPdzeHsGnZnT806DVPnQ1bmlP goYbO0tRq/MsQyT4/x+ItKlx25y4nqjtHNu8FRv304tKciJxVINMAd/e0J0DL6Yq hlT/isdszIMk4BJP5S0infaTsurYI6CMhUOd9UGEtJW0bHqgBWg+AG5NgImCdzrb TgDTDBVJQPWfJI3gqrtV4vZf5sril9jKyYlipcLOwIxbRWcBFnpVBe2PlFS+hLU= =3nZl -----END PGP SIGNATURE----- --NrwwJDUhLWqBVswDBUg5JcN440tLWPltn-- From nobody Wed May 18 14:12:43 2016 Return-Path: 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 9D61C12D6FA; Wed, 18 May 2016 14:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 KyHYqbti8uUp; Wed, 18 May 2016 14:12:40 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8546712D746; Wed, 18 May 2016 14:12:40 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B502A28B003D; Wed, 18 May 2016 17:12:39 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id A7A831F8056; Wed, 18 May 2016 17:12:39 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_33DADD0E-DA1E-40E0-B624-44E2448304B7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> Date: Wed, 18 May 2016 17:12:28 -0400 Message-Id: <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-sidr-rpsl-sig@ietf.org, Sandra Murphy , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, Stephen Farrell Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 21:12:42 -0000 --Apple-Mail=_33DADD0E-DA1E-40E0-B624-44E2448304B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 comments inline. speaking as a regular ol=92 wg member On May 18, 2016, at 12:20 PM, Brian Haberman = wrote: > Hiya Stephen, >=20 > On 5/18/16 12:09 PM, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> On 18/05/16 17:06, Brian Haberman wrote: >>> Hiya Stephen, >>>=20 >>> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-sidr-rpsl-sig-11: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> I'd like to check one thing - this may be needed for strict >>>> compliance with RPKI thing but it seems kinda weird to also >>>> impose that here, but anyway... >>>>=20 >>>> Is 3.2 step 1 needed? That seems like useless complexity >>>> here. If it is needed, how does the verifier check that >>>> it's really a single-use? I don't see the point TBH. >>>>=20 >>>=20 >>> This text was driven by the statement in RFC 6487 (Section 3) that = says: >>>=20 >>> The private key associated with an EE certificate is used to sign = a >>> single RPKI signed object, i.e., the EE certificate is used to >>> validate only one object. >>>=20 >>> Step 1 in 3.2 is there so that this approach follows the above = directive >>> on the use of the RPKI infrastructure/certificates. >>=20 >> Well... sure. But what is the benefit here? IIRC that was >=20 > I *think* the benefit is supposed to be compliance with the RPKI = approach... >=20 >> something related to making more fine-grained revocation >> possible or something which doesn't seem that useful here >> since a verifier will likely already have processed stuff >> already or am I mixed up? >=20 > I don't think you are mixed up, but I will let others in SIDR chime = in=85 There was at one point in the history of resource certificates the idea = that EE certs could be used multiple times. (EE certs even had their = own manifests!) The signed object definition encapsulated the EE cert used to verify the = signature. That revocation of the signed object could be accomplished = by revoking the EE cert. Which meant that the EE cert should be used = just to sign that one object, as Stephen says. (otherwise chaos ensues) As the only defined use of EE certs at the time of the publication of = 6487 was the use to verify signed objects, the text about EE certs was = reduced to just that necessary to support the single-use. This is different. The validity of the rpsl object is not tied to the = validity of the EE cert. The comments from the wg were that this draft = should talk about the syntax of the new attribute, not the = authorization/semantics. So revocation of the EE cert in this case = would/might not have the effect of revoking the rpsl object. I = personally don=92t think it likely that it ever will, but that=92s IMHO = only. So it is a moot question as to whether the single-use is a part of =93the = RPKI approach=94 for this rpsl-sig use. >=20 >>=20 >> If there's no benefit, it seems like that adds a bunch of >> CA code just for fun (or "compliance" maybe;-) curious: how would this single-use requirement add anything to the CA = code? If the requirement is in 6487, the CA code would already have the = checks. I ask only because I might be missing something. >=20 > I could very easily see dropping step 1 from 3.2 and simply augmenting > the intro sentence with something about certs/keys generated per 3487. I think you mean 6487? You have already suggested removing the SIA requirement from 6487 for = the EE certs rpsl-sig uses, so these EE certs are already a different = sort of EE cert. Other special requirements as necessary. =97Sandy, speaking as a regular ol=92 wg member --Apple-Mail=_33DADD0E-DA1E-40E0-B624-44E2448304B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXPNrGAAoJEHplpQeet0IZVcoP/RlCY4jLIljdg+wfiOMQwaBg y4pJdCU4nr42kuY54jRljUcO4pK1AZ0YNZYucG2Gz2YyHc4OH5pqWf2CSVWWMKnO EHt6trtNLY/0+x17JZhlz1g2elCUveEHxOuO7uH6v6gCQQtHLmLhSdfGSUoLVbHP +egH6zStEZ3wvv28jnBitf5nmXCMik8RNBQkQXLDVXPfLT0n7VrubVTI2qqzbfWk tiItDvzWivCTPwyYRWGHwfSNk0yIONGlXOw9U8m9xUWjo7xkSF2E2Fb/Uhktso45 4JPjGWQ6FMJLDsKKeiRBs9GNiwcHHWezHSe9L5xog8PrO1VLQqk7MCNRUBI1NwEN avyASvWfWRwKx0yRbC1cIMXuJsZWC4V4GZXmLvQ3AcMulUeMwti8WmL2dOEmBpBm G6pfbUZm3nSqdXp3XzBv5gV4YFqsscA+GN+N3Rg14LIHeN6LNbdly4YtnPOM9r6o 28YwNInibcA59XqDg9fXEgZ7rFraUjJRMx/EI6zDlsVWB/7hIoiSdRHeg/1GUPG+ sBL4zmRH/ILSZMLP1TxeWweof7ExcveyxPwQup5nZIBiIKjtBwRx6n25h9Hx5D4j Xg3DCItZF54Jnw0gIwInE/mnMwHOqKgsyNBEjgw+jTpJWh4zYqIgvrE2ISjQWGms EZgYBAKGnlhQTa5K3Dsy =YRUf -----END PGP SIGNATURE----- --Apple-Mail=_33DADD0E-DA1E-40E0-B624-44E2448304B7-- From nobody Wed May 18 14:23:46 2016 Return-Path: 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 1049912D75E; Wed, 18 May 2016 14:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 btDPMUoNnDnb; Wed, 18 May 2016 14:23:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA1112D74D; Wed, 18 May 2016 14:23:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61E0ABE2C; Wed, 18 May 2016 22:23:41 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MVb-8tAFU9e; Wed, 18 May 2016 22:23:39 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D9065BDD0; Wed, 18 May 2016 22:23:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463606619; bh=YTQi5UhjZhDRhwdHS4rQrKE6ShbBCMnlcx7lKDs/CP8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RQE10369YEMkMyfKmPmlFzbrhe3d8lVvza/v/oii8qreTirbonVPlTetURWpjI2bF QhanakR6eJjeU+ncAtnRQNvIsC6mjcy6acqW2+R6p7R1WjYkPJ4zJ6YDOws1Eqd4bC e+bJP445iFSURorQrGQUdr0LKVsfzK1QXtbp+1xo= To: Sandra Murphy , Brian Haberman References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573CDD5A.4030206@cs.tcd.ie> Date: Wed, 18 May 2016 22:23:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="64AtTa3ThqH6kcF52u2b63ieHPRkt0Wpc" Archived-At: Cc: sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 21:23:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --64AtTa3ThqH6kcF52u2b63ieHPRkt0Wpc Content-Type: multipart/mixed; boundary="3sIIeq9R7TasSODv9OQGGwXOIB2NiORwc" From: Stephen Farrell To: Sandra Murphy , Brian Haberman Cc: draft-ietf-sidr-rpsl-sig@ietf.org, sidr-chairs@ietf.org, The IESG , sidr@ietf.org Message-ID: <573CDD5A.4030206@cs.tcd.ie> Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> In-Reply-To: <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> --3sIIeq9R7TasSODv9OQGGwXOIB2NiORwc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sandy, On 18/05/16 22:12, Sandra Murphy wrote: > comments inline. speaking as a regular ol=E2=80=99 wg member >=20 > On May 18, 2016, at 12:20 PM, Brian Haberman > wrote: >=20 >> Hiya Stephen, >>=20 >> On 5/18/16 12:09 PM, Stephen Farrell wrote: >>>=20 >>> Hiya, >>>=20 >>> On 18/05/16 17:06, Brian Haberman wrote: >>>> Hiya Stephen, >>>>=20 >>>> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>>>> Stephen Farrell has entered the following ballot position >>>>> for draft-ietf-sidr-rpsl-sig-11: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and >>>>> reply to all email addresses included in the To and CC lines. >>>>> (Feel free to cut this introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>>> more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found >>>>> here:=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------------------------------------------------------------------= --- >>>>> >>>>>=20 DISCUSS: >>>>> -------------------------------------------------------------------= --- >>>>> >>>>> >>>>> >>>>>=20 I'd like to check one thing - this may be needed for strict >>>>> compliance with RPKI thing but it seems kinda weird to also=20 >>>>> impose that here, but anyway... >>>>>=20 >>>>> Is 3.2 step 1 needed? That seems like useless complexity=20 >>>>> here. If it is needed, how does the verifier check that it's >>>>> really a single-use? I don't see the point TBH. >>>>>=20 >>>>=20 >>>> This text was driven by the statement in RFC 6487 (Section 3) >>>> that says: >>>>=20 >>>> The private key associated with an EE certificate is used to >>>> sign a single RPKI signed object, i.e., the EE certificate is >>>> used to validate only one object. >>>>=20 >>>> Step 1 in 3.2 is there so that this approach follows the above >>>> directive on the use of the RPKI infrastructure/certificates. >>>=20 >>> Well... sure. But what is the benefit here? IIRC that was >>=20 >> I *think* the benefit is supposed to be compliance with the RPKI >> approach... >>=20 >>> something related to making more fine-grained revocation possible >>> or something which doesn't seem that useful here since a verifier >>> will likely already have processed stuff already or am I mixed >>> up? >>=20 >> I don't think you are mixed up, but I will let others in SIDR chime >> in=E2=80=A6 >=20 > There was at one point in the history of resource certificates the > idea that EE certs could be used multiple times. (EE certs even had > their own manifests!) >=20 > The signed object definition encapsulated the EE cert used to verify > the signature. That revocation of the signed object could be > accomplished by revoking the EE cert. Which meant that the EE cert > should be used just to sign that one object, as Stephen says. > (otherwise chaos ensues) >=20 > As the only defined use of EE certs at the time of the publication of > 6487 was the use to verify signed objects, the text about EE certs > was reduced to just that necessary to support the single-use. >=20 > This is different. The validity of the rpsl object is not tied to > the validity of the EE cert. The comments from the wg were that this > draft should talk about the syntax of the new attribute, not the > authorization/semantics. So revocation of the EE cert in this case > would/might not have the effect of revoking the rpsl object. I > personally don=E2=80=99t think it likely that it ever will, but that=E2= =80=99s IMHO > only. >=20 > So it is a moot question as to whether the single-use is a part of > =E2=80=9Cthe RPKI approach=E2=80=9D for this rpsl-sig use. But that means that there is no reason to include the requirement here then or am I missing something? Deleting that "step" in the signing process would seem like a good idea so. (Assuming that current implementers, if any, are fine with that.) >=20 >>=20 >>>=20 >>> If there's no benefit, it seems like that adds a bunch of CA code >>> just for fun (or "compliance" maybe;-) >=20 > curious: how would this single-use requirement add anything to the CA > code? If the requirement is in 6487, the CA code would already have > the checks. I ask only because I might be missing something. What I was trying to say was that requiring signers of this to include all the CA code is the problem/oddity, esp if there's no real benefit. So the single-use thing doesn't add to the CA code, it adds a need for the CA code in the wrong place. And I guess if the spec says "once only" then I can well imagine some poor verifier implementer keeping some kind of cache and checking it'd not seen a signature before or something like that. And that'd also be kinda pointless code too I think. >>=20 >> I could very easily see dropping step 1 from 3.2 and simply >> augmenting the intro sentence with something about certs/keys >> generated per 3487. >=20 > I think you mean 6487? >=20 > You have already suggested removing the SIA requirement from 6487 for > the EE certs rpsl-sig uses, so these EE certs are already a different > sort of EE cert. Other special requirements as necessary. Great - so no need to do the single-use thing here then? But I may not be grokking all the consequences of the above so please do correct me if I'm wrong. Cheers, S. >=20 > =E2=80=94Sandy, speaking as a regular ol=E2=80=99 wg member >=20 >=20 --3sIIeq9R7TasSODv9OQGGwXOIB2NiORwc-- --64AtTa3ThqH6kcF52u2b63ieHPRkt0Wpc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXPN1aAAoJEC88hzaAX42iEBkH/11eiZZ8oyJ/O6Kuv/syzGgp J5GiO/jVJIYXAQgmn/9dGGIvoPNVWEdJAfnMgJvil7wkV4OWo6ZFta2QiwgPHnX7 gxQ6/BvqBfcVAnXeEGRZ+uktmOzcN1QlTZrlO/Y9Of6tX3/DtM5WLjxNM49JjEQu QfTTV9UR/r699A3qy93Xp2a0NF1yi92eHOi45VQ5zcsKRwFa92vNxJfQAsqOFNSh bu/CDHhv1sqbT5dud3swAR+W4so+XqA6LaDUs/yrhy0WT/815J9vMstxvhgJnL4v 8n5HRIh31vGo5q9VoDDrlyghdGghTi4k7sAYJ0UfuwrCXeagL+mjWGBe7zQIdoI= =t1m5 -----END PGP SIGNATURE----- --64AtTa3ThqH6kcF52u2b63ieHPRkt0Wpc-- From nobody Wed May 18 15:39:19 2016 Return-Path: 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 84B1812D790 for ; Wed, 18 May 2016 15:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 wW_WRA7kd_H2 for ; Wed, 18 May 2016 15:39:11 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 9431E12D792 for ; Wed, 18 May 2016 15:39:10 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id w36so34353633qge.3 for ; Wed, 18 May 2016 15:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc; bh=MM+pbhrKJBJxesnYS+K0WZsonpfblsVO61teZTXkOH8=; b=RkS0Fo1c5UPBYGSgpcF3ZnSvDqnE2Ionx34lqoVZt3owdWUZ0I+wm7gMCQdSQTlTaA Ltbd6Hv2ajzwwJzg3ve5rKYqyP+9g4T3Y80RtN6+e/n8E75+dXrx5CEgXptHptUQzfff nxBdnNobPfRHzjdE/o3OvcoU7Cdjdmozs8uJraiUvhPtdaGI9mjssp3cy5ClMoz/pbls YnyfDdQhhkJmS3RIZfieOTsZzEcgYvBPfFEnqgw5+L/YmLVyGJAP1x3wi80DL2A8dHt+ tQSimru0kubYlgefA4EKyIcPCNW6sZ7u4UbdVWQWdIML5q/7DjRCaFnD/rkBErRbenOj Lrjw== 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:cc; bh=MM+pbhrKJBJxesnYS+K0WZsonpfblsVO61teZTXkOH8=; b=kw1nEX6ozBYYAOrSlkIilHFetXwUqaiRnNU0EV1HQ7+N8nBAaLL79QxcQOox5pUw3B CGac+zHpt3DfqJUOsTR9XI8wY2ql0TmFQ8LC1+LxlIDvLRL+hkydzeTssUAzOuyQaLub OtFI4CkLD4KTqBgzc/1T2gvkC3a5CDEqQ4A+8V+Xydd0vf9VzcrEhQma9wVkwkp/BhJl Mt/Uqrghpd1Mq0HeerP8s5THOhldj0mzPh/O+7Hk+KnL0p1XKwuNEtvkUuA80ACFBAMP tjIsEBmEltDvhEnOstO54uFp35YGjyIvEWH/egOxgshsf8aVwR5fj9qXbdDpkkC3HtsH 8JrA== X-Gm-Message-State: AOPr4FXcSm7JmXZrEYwWRCgL2kCiS4J7LqLXbR67dR/l2nSZ5C/KH16h5I0bGiBc7bVZ5LodH0XBCfiJeu4dJA== MIME-Version: 1.0 X-Received: by 10.140.197.5 with SMTP id s5mt11438926qha.17.1463611149685; Wed, 18 May 2016 15:39:09 -0700 (PDT) Received: by 10.55.190.197 with HTTP; Wed, 18 May 2016 15:39:09 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:2947:a5f7:dc05:72b0] In-Reply-To: References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> Date: Thu, 19 May 2016 08:39:09 +1000 Message-ID: From: George Michaelson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Sandra L. Murphy" , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-rpsl-sig@ietf.org, "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:39:13 -0000 I would rather the sigs were signed by ee certs which were in the blob, than have to make an external reference and I would rather we varied the compliance needs to remove a pointless external ref. If there has to be a ref, I think making it mandated to a specific scheme is over specifying, especially in a context where we might begin to understand *where you get cryptographic materials from is less important than proving who said them*. Rsync is a bad fit. for the actual signing cert, Inline is better. It can refer to whatever chain it likes. -G On Thu, May 19, 2016 at 1:02 AM, Brian Haberman wrote: > Hi Tim, > > On 5/18/16 10:32 AM, Tim Bruijnzeels wrote: >> Hi, >> >>> On 18 May 2016, at 15:08, Brian Haberman >>> wrote: >>> >>> Hi Terry, >>> >>> On 5/17/16 11:37 PM, Terry Manderson wrote: >>>> Terry Manderson has entered the following ballot position for >>>> draft-ietf-sidr-rpsl-sig-11: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to >>>> all email addresses included in the To and CC lines. (Feel free >>>> to cut this introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>> more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found >>>> here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> > DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> > Thank you for putting substantial effort into this document. >>>> >>>> I have a few discusses. I hope they can be resolved quickly. >>>> >>>> In Section 2.1. The reference to the aligned certificate which >>>> has the same private key that signed the RPSL object is >>>> mandatory, and defined by a RSYNC URL or a HTTP(S) URL. My >>>> question surrounds the "or". The architecture of RPKI (IIRC) is >>>> centered around RSYNC, and thus SIA/AIA values MUST have a RSYNC >>>> URL, and MAY have other types. By this are you leaving it to the >>>> issuing party to control the RPKI Distribution mechanisms of the >>>> Replying Party? I am quite comfortable with "or" personally, >>>> however this facet of fetching the RPSL Certificate to validate >>>> the private key usage is seemingly orthogonal to the RPKI >>>> architecture of RSYNC preferred and should be called out if 'or' >>>> is the clear intention. Or, has the consensus of the WG moved on >>>> from being wedded to RSYNC? >>> >>> I am not aware of the WG moving away from their rsync leanings... >> >> My take on this: for the moment I would stick to rsync as it's >> required and EE certificates appearing in the rsync repository, and >> leave out http(s). >> > > If the consensus is to remove mention of an http(s) URI, I can live with > that. The current state of affairs within the SIDR documentation is such > that only an rsync URI will be feasible in the near future. I don't > believe that the mention of an http(s) URI in this context affects that > one way or the other. > > Regards, > Brian > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Wed May 18 15:45:17 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFED312D798; Wed, 18 May 2016 15:45:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518224512.14689.8918.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 15:45:12 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sandy@tislabs.com Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-rpsl-sig-11: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:45:13 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-rpsl-sig-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am also curious about the point in Stephen's discuss. From nobody Wed May 18 21:07:18 2016 Return-Path: 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 93E3312B032; Wed, 18 May 2016 21:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 khVhpD6A8UEt; Wed, 18 May 2016 21:07:11 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A17B12B018; Wed, 18 May 2016 21:07:11 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 18 May 2016 21:07:08 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Wed, 18 May 2016 21:07:08 -0700 From: Terry Manderson To: Brian Haberman , The IESG Thread-Topic: Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) Thread-Index: AQHRsQZpOwPGEWtT2U6DxoMlXXHouJ/AwrmA Date: Thu, 19 May 2016 04:07:07 +0000 Message-ID: References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3546511621_11318057" MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpsl-sig@ietf.org" , "Sandra L. Murphy" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 04:07:12 -0000 --B_3546511621_11318057 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Brian, On 18/05/2016, 11:08 PM, "Brian Haberman" wrote: > >You are correct that the use of the RPKI repository is one of >convenience. My original implementation of this approach used non-RPKI >certificates. I would be fine with putting a statement in the >Introduction along the lines of: > >"While the approach outlined in this document mandates the use of the >RPKI for certificate distribution, it is not dependent upon the RPKI for >correct functionality. Equivalent functionality can be achieved with a >more traditional certificate authority, RFC 3779 extensions within the >certificates, and the appropriate trust anchor material to verify the >digital signature." That is a fine snippet to include. Thank you. > >> >> The Signature expiration time field ("x") currently has no time >> constraints, and I'm very surprised that it is optional with the text in >> s2.5, given that the expiration time, by my reading, could not be beyond >> the 'not after' time of the corresponding certificate. Can you please >> instruct me as to what the consensus position on this was? A criticism >>of >> many IRRs is that data becomes stale. have the signature expiration time >> field could aide in data freshness models and reduce load on automated >> import and validation of these RPSL signatures. > >The validity of the signature is driven by the notAfter field of the >certificate described in 6487. My implementation does the validation >based on notAfter regardless of what is included in the "x" field. I >view "x" as a simple way for RPSL object signers to indicate the >lifetime, but not the authoritative way. Understood. I was considering a more operational triage of the signed objects prior to validation. But in reflection that can introduce an unintentional error situation. Put aside this item. > >> >> And lastly, IRRs tend to run over the (legacy?) whois port 43 that >> doesn't provide channel layer security. This means that while signature >> provide a means of detecting modification it may not stop a a MiTM event >> where the entire object is omitted. Do you agree? if so that might be >> appropriate for the Security Considerations section. >> > >I agree with the potential MiTM attack described, but view that as >orthogonal to digital signatures providing integrity protection. This >type of attack could easily occur regardless of whether objects are >signed or not. Correct. I raise the point so that people who implement and/or use rpsl-sig do not accidentally assume that by adding a signature some form of magic happens that unreservedly protects the object - you can take this now as 'comment' fodder. > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> one nit: >> >> "MUST reject the signature and threat the object as a regular" I think >> you mean `s/threat/treat` > >Fixed in my pending edit buffer. Thanks > >> >> Misc comments: >> >> * Thank you for the very clear canonicalisation requirements! >> >> * For route6 objects, where two resource holder's signatures considered >> such that it might address the inability to properly sign the RPSL when >> one holder possesses the ASN and another possesses the prefix? (just a >> comment, nothing more) >> > >Not sure I can parse the above unless s/where/were/... If so, that was >originally in the document prior to -09, but the consensus of the WG was >to remove multiple signature support. Yes, I typo'd. Thanks for the info on the WG consensus for multiple signature support. I'll clear my discuss shortly. Cheers Terry --B_3546511621_11318057 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFP/W IY0nknLH1K/3iymNNRieCItLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE2MDUxOTA0MDcwMVowDQYJKoZIhvcNAQEBBQAEggEAO0LntpaFTEWZW74b8EYk ZdJhVAhUnHkjssx4g63xn7YNDSQ9HEzja8a3dMCGM9/jyHUN/rrhNjmafzBuI6TblbQ/APdB 6rx2hikikiFzjaAWDMauEHdIS0rLN4+zq2iB7J33/FAf9vOwK+WmqF0CoxviF2OPskiOi+h0 reBC6KvFWpe9L4mlpFw1ynmsWBUYTgcdERq8m4/0zW4+4nDGl7ImTqwnIjGducWcohzbOE6x 1IhBGgW9PHNa1pQLvXriV6SjSUybAejw+zxcnVe9AVi6hPCvJussdfDXwErffGb4GueQI4D6 cYsbn610wrEZEKs+nTH+ztmjN9tsRaSJDA== --B_3546511621_11318057-- From nobody Thu May 19 00:43:42 2016 Return-Path: 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 B28B812B074; Thu, 19 May 2016 00:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 RCUTryx5u93p; Thu, 19 May 2016 00:43:36 -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 DF9DB12B03E; Thu, 19 May 2016 00:43:35 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1b3IcD-0007VF-1c; Thu, 19 May 2016 09:43:31 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-195.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1b3IcC-0008NN-NQ; Thu, 19 May 2016 09:43:28 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Thu, 19 May 2016 09:43:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> To: George Michaelson X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ---------- X-RIPE-Spam-Report: Spam Total Points: -10.8 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 -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197aaf9822b651c7f2bffab93391130d73 Archived-At: Cc: "sidr@ietf.org" , sidr chairs , The IESG , draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 07:43:38 -0000 Hi all, Actually, yes, I agree with George on in-line. In-line would have my preference. Include the entire EE certificate in = the signature field. This way it does not need to be fetched separately, = and it does not need to appear in a repository or a manifest. Mandate = that the EE certificate is signed by CA certificate in the RPKI (i.e. no = longer chain possible). The EE certificate should have an AIA and AKI = that can then be easily referenced against known CA certificates that a = validator found. So in short: a validator can do its normal top-down validation for a TA. = And to perform bottom-up validation of a signed RPSL object the process = of validating the EE cert would be fairly simple -> find a CA cert with = SKI matching the AKI of the EE, verify the signature of the EE (proof of = possession), verify the CRL. Omitting the other checks here - would be = good to specify this explicitly in the document, but for the discussion = here seems excessive. I think there was some discussion around this earlier and back then the = thought was that we wouldn't want to make the RPSL objects bigger. = However, I don't know if that should be a concern. The way I see it = looking at our own whois implementation I imagine that this field could = actually only be shown to RPs when they supply an additional flag, if = size is a concern. And in our web UI (ad-hoc queries by humans) we would = not show the signature field as is, but process it and highlight signed = fields somehow. Tim > On 19 May 2016, at 00:39, George Michaelson wrote: >=20 > I would rather the sigs were signed by ee certs which were in the > blob, than have to make an external reference and I would rather we > varied the compliance needs to remove a pointless external ref. >=20 > If there has to be a ref, I think making it mandated to a specific > scheme is over specifying, especially in a context where we might > begin to understand *where you get cryptographic materials from is > less important than proving who said them*. >=20 > Rsync is a bad fit. for the actual signing cert, Inline is better. It > can refer to whatever chain it likes. >=20 > -G >=20 > On Thu, May 19, 2016 at 1:02 AM, Brian Haberman > wrote: >> Hi Tim, >>=20 >> On 5/18/16 10:32 AM, Tim Bruijnzeels wrote: >>> Hi, >>>=20 >>>> On 18 May 2016, at 15:08, Brian Haberman >>>> wrote: >>>>=20 >>>> Hi Terry, >>>>=20 >>>> On 5/17/16 11:37 PM, Terry Manderson wrote: >>>>> Terry Manderson has entered the following ballot position for >>>>> draft-ietf-sidr-rpsl-sig-11: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to >>>>> all email addresses included in the To and CC lines. (Feel free >>>>> to cut this introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>>> more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found >>>>> here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>>=20 >> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >> Thank you for putting substantial effort into this document. >>>>>=20 >>>>> I have a few discusses. I hope they can be resolved quickly. >>>>>=20 >>>>> In Section 2.1. The reference to the aligned certificate which >>>>> has the same private key that signed the RPSL object is >>>>> mandatory, and defined by a RSYNC URL or a HTTP(S) URL. My >>>>> question surrounds the "or". The architecture of RPKI (IIRC) is >>>>> centered around RSYNC, and thus SIA/AIA values MUST have a RSYNC >>>>> URL, and MAY have other types. By this are you leaving it to the >>>>> issuing party to control the RPKI Distribution mechanisms of the >>>>> Replying Party? I am quite comfortable with "or" personally, >>>>> however this facet of fetching the RPSL Certificate to validate >>>>> the private key usage is seemingly orthogonal to the RPKI >>>>> architecture of RSYNC preferred and should be called out if 'or' >>>>> is the clear intention. Or, has the consensus of the WG moved on >>>>> from being wedded to RSYNC? >>>>=20 >>>> I am not aware of the WG moving away from their rsync leanings... >>>=20 >>> My take on this: for the moment I would stick to rsync as it's >>> required and EE certificates appearing in the rsync repository, and >>> leave out http(s). >>>=20 >>=20 >> If the consensus is to remove mention of an http(s) URI, I can live = with >> that. The current state of affairs within the SIDR documentation is = such >> that only an rsync URI will be feasible in the near future. I don't >> believe that the mention of an http(s) URI in this context affects = that >> one way or the other. >>=20 >> Regards, >> Brian >>=20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu May 19 02:31:17 2016 Return-Path: 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 0B12712B00E; Thu, 19 May 2016 02:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ffGfN2FthgL8; Thu, 19 May 2016 02:31:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081E212B049; Thu, 19 May 2016 02:31:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5749DBE32; Thu, 19 May 2016 10:31:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG_pnLNFYk8p; Thu, 19 May 2016 10:31:02 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EB637BDCC; Thu, 19 May 2016 10:31:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463650262; bh=E3ewBJpmeWJC2S9d4v3Hd7/N3AJEHO+tbpBZevwjh9g=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qgKHeErhIl1aYKQ+/K47wNdMV5aLTj4kzDWNsqCgtwoZQ2yogNvnqf9paP+BxzSjX g1Cf5DeeZ0BKceQHONcMRldjQqvx5Iu422rX17dvD9Y8M4l4xP6lGoSBqz7Qhb5ve6 HB/2w3Zd0ydXEehFTfstIK4/rpni+ljnpLLk3t74= To: Tim Bruijnzeels , George Michaelson References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573D87D5.2060609@cs.tcd.ie> Date: Thu, 19 May 2016 10:31:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070703000309030300010501" Archived-At: Cc: "Sandra L. Murphy" , sidr chairs , The IESG , draft-ietf-sidr-rpsl-sig@ietf.org, "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 09:31:11 -0000 This is a cryptographically signed message in MIME format. --------------ms070703000309030300010501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/05/16 08:43, Tim Bruijnzeels wrote: > Hi all, >=20 > Actually, yes, I agree with George on in-line. >=20 > In-line would have my preference. Include the entire EE certificate > in the signature field. This way it does not need to be fetched > separately, and it does not need to appear in a repository or a > manifest. Mandate that the EE certificate is signed by CA certificate > in the RPKI (i.e. no longer chain possible). The EE certificate > should have an AIA and AKI that can then be easily referenced against > known CA certificates that a validator found. Were I designing that I'd have a separate new attribute that could contain one or more certs and I'd say that if the c=3D field/URI in the signature attribute is empty (or has some specified value such as "inband") then that means "look at the cert-bucket attribute in this file." The cert-bucket would then be expected to contain a base64 encoded cert chain. Consumers of that attribute would have to ensure that nothing in it affects the local trust point store but can otherwise throw the lot into their cert path processing engine. Assuming that the signatures on these files aren't very long-lived you can probably input the cert-bucket attribute into the signature. If signatures commonly need to be ok to verify even after certificate expiry (e.g. if a new cert was issued for the same key pair in an update operation) then you'd not want the cert-bucket in the signature maybe. There're various non-compelling but goodish reasons to do it that way. Maybe the best ones are around making it easy to use existing tooling (openssl etc) for the verifier. I'm not sure what benefit ensues from insisting that the EE cert very strictly adhere to all ithe RPKI rules, but I reckon you do want to be able to use the same PKI for sure. So were it me, I'd try craft text saying "you're very likely to want to use an RPKI CA for issuing the cert used to verify the signature attribute so your code MUST support doing that, but there can be other equally standard PKI options too that are useful to support." >=20 > So in short: a validator can do its normal top-down validation for a > TA. And to perform bottom-up validation of a signed RPSL object the > process of validating the EE cert would be fairly simple -> find a CA > cert with SKI matching the AKI of the EE, verify the signature of the > EE (proof of possession), verify the CRL. Omitting the other checks > here - would be good to specify this explicitly in the document, but > for the discussion here seems excessive. Yep. Cheers, S. >=20 > I think there was some discussion around this earlier and back then > the thought was that we wouldn't want to make the RPSL objects > bigger. However, I don't know if that should be a concern. The way I > see it looking at our own whois implementation I imagine that this > field could actually only be shown to RPs when they supply an > additional flag, if size is a concern. And in our web UI (ad-hoc > queries by humans) we would not show the signature field as is, but > process it and highlight signed fields somehow. >=20 > Tim >=20 >=20 >> On 19 May 2016, at 00:39, George Michaelson >> wrote: >>=20 >> I would rather the sigs were signed by ee certs which were in the=20 >> blob, than have to make an external reference and I would rather >> we varied the compliance needs to remove a pointless external ref. >>=20 >> If there has to be a ref, I think making it mandated to a specific=20 >> scheme is over specifying, especially in a context where we might=20 >> begin to understand *where you get cryptographic materials from is=20 >> less important than proving who said them*. >>=20 >> Rsync is a bad fit. for the actual signing cert, Inline is better. >> It can refer to whatever chain it likes. >>=20 >> -G >>=20 >> On Thu, May 19, 2016 at 1:02 AM, Brian Haberman=20 >> wrote: >>> Hi Tim, >>>=20 >>> On 5/18/16 10:32 AM, Tim Bruijnzeels wrote: >>>> Hi, >>>>=20 >>>>> On 18 May 2016, at 15:08, Brian Haberman >>>>> wrote: >>>>>=20 >>>>> Hi Terry, >>>>>=20 >>>>> On 5/17/16 11:37 PM, Terry Manderson wrote: >>>>>> Terry Manderson has entered the following ballot position >>>>>> for draft-ietf-sidr-rpsl-sig-11: Discuss >>>>>>=20 >>>>>> When responding, please keep the subject line intact and >>>>>> reply to all email addresses included in the To and CC >>>>>> lines. (Feel free to cut this introductory paragraph, >>>>>> however.) >>>>>>=20 >>>>>>=20 >>>>>> Please refer to=20 >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT >>>>>> positions. >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be >>>>>> found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> >>> >>>>>>=20 DISCUSS: >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> >>>>>> >>> >>>>>>=20 Thank you for putting substantial effort into this document. >>>>>>=20 >>>>>> I have a few discusses. I hope they can be resolved >>>>>> quickly. >>>>>>=20 >>>>>> In Section 2.1. The reference to the aligned certificate >>>>>> which has the same private key that signed the RPSL object >>>>>> is mandatory, and defined by a RSYNC URL or a HTTP(S) URL. >>>>>> My question surrounds the "or". The architecture of RPKI >>>>>> (IIRC) is centered around RSYNC, and thus SIA/AIA values >>>>>> MUST have a RSYNC URL, and MAY have other types. By this >>>>>> are you leaving it to the issuing party to control the RPKI >>>>>> Distribution mechanisms of the Replying Party? I am quite >>>>>> comfortable with "or" personally, however this facet of >>>>>> fetching the RPSL Certificate to validate the private key >>>>>> usage is seemingly orthogonal to the RPKI architecture of >>>>>> RSYNC preferred and should be called out if 'or' is the >>>>>> clear intention. Or, has the consensus of the WG moved on=20 >>>>>> from being wedded to RSYNC? >>>>>=20 >>>>> I am not aware of the WG moving away from their rsync >>>>> leanings... >>>>=20 >>>> My take on this: for the moment I would stick to rsync as it's=20 >>>> required and EE certificates appearing in the rsync repository, >>>> and leave out http(s). >>>>=20 >>>=20 >>> If the consensus is to remove mention of an http(s) URI, I can >>> live with that. The current state of affairs within the SIDR >>> documentation is such that only an rsync URI will be feasible in >>> the near future. I don't believe that the mention of an http(s) >>> URI in this context affects that one way or the other. >>>=20 >>> Regards, Brian >>>=20 >>>=20 >>>=20 >>> _______________________________________________ sidr mailing >>> list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr >>>=20 >>=20 >> _______________________________________________ sidr mailing list=20 >> sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr >=20 --------------ms070703000309030300010501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTkw OTMxMDFaMC8GCSqGSIb3DQEJBDEiBCDhuLjAjYX4QudCR+RKBXmfYkv8DXJbvQxWGQ6q7hjS 4zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCfaZF4uyowAXUvdzv0aBRCrtXRLtItFK4BokBE9f7m3hLnIsi0lkLk qZYPnJ3+8L+z8Gm0EtKCngbqbBlvOCmWeBFp2Dp6kXIZ2oQnsTtX4DA7adpUskMhq3EU4XRp s1Sex16Ee2BRA1xfLN3w9PvZc3cxAVp/JPcmBn7cbo4PxkYQVxX+WxqEttOW9pVqMJ2HZo6e flX+n9Ulm1UwDnOv2rJnW1G2a7dQNRIBm6meDfM0pyHBmzKKh+kKU0W0K2VPT93j73iagzKf dDI2zigqR+FHx9ZwNQMhLpx5oEbFB32+TMJi7qP0H4TriLeTw3Phu8E1bWZplhI6J5AAAo2b AAAAAAAA --------------ms070703000309030300010501-- From nobody Thu May 19 05:12:10 2016 Return-Path: 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 42F4212B004; Thu, 19 May 2016 05:12: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 WyNtiF6hYnvy; Thu, 19 May 2016 05:11:58 -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 6F4AB12B015; Thu, 19 May 2016 05:11:58 -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 49E8C880E4; Thu, 19 May 2016 05:11:58 -0700 (PDT) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6D468328081A; Thu, 19 May 2016 05:11:57 -0700 (PDT) To: Stephen Farrell , Sandra Murphy References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> <573CDD5A.4030206@cs.tcd.ie> From: Brian Haberman Message-ID: <087861c3-d506-2ab8-0ecb-df09dc293678@innovationslab.net> Date: Thu, 19 May 2016 08:11:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <573CDD5A.4030206@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mVM4Q03keGclJonLXu3l8hBMh9pAcj5Ix" Archived-At: Cc: sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:12:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mVM4Q03keGclJonLXu3l8hBMh9pAcj5Ix Content-Type: multipart/mixed; boundary="vD4gFu2gpsqOMCAgHSVAHxPccHq7oQE5p" From: Brian Haberman To: Stephen Farrell , Sandra Murphy Cc: draft-ietf-sidr-rpsl-sig@ietf.org, sidr-chairs@ietf.org, The IESG , sidr@ietf.org Message-ID: <087861c3-d506-2ab8-0ecb-df09dc293678@innovationslab.net> Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> <573CDD5A.4030206@cs.tcd.ie> In-Reply-To: <573CDD5A.4030206@cs.tcd.ie> --vD4gFu2gpsqOMCAgHSVAHxPccHq7oQE5p Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Stephen, On 5/18/16 5:23 PM, Stephen Farrell wrote: >=20 > Hi Sandy, >=20 > On 18/05/16 22:12, Sandra Murphy wrote: >> comments inline. speaking as a regular ol=E2=80=99 wg member >> >> On May 18, 2016, at 12:20 PM, Brian Haberman >> wrote: >> >>> Hiya Stephen, >>> >>> On 5/18/16 12:09 PM, Stephen Farrell wrote: >>>> >>>> Hiya, >>>> >>>> On 18/05/16 17:06, Brian Haberman wrote: >>>>> Hiya Stephen, >>>>> >>>>> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>>>>> Stephen Farrell has entered the following ballot position >>>>>> for draft-ietf-sidr-rpsl-sig-11: Discuss >>>>>> >>>>>> When responding, please keep the subject line intact and >>>>>> reply to all email addresses included in the To and CC lines. >>>>>> (Feel free to cut this introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>>>> more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found >>>>>> here:=20 >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> > DISCUSS: >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> >>>>>> >>>>>> > I'd like to check one thing - this may be needed for strict >>>>>> compliance with RPKI thing but it seems kinda weird to also=20 >>>>>> impose that here, but anyway... >>>>>> >>>>>> Is 3.2 step 1 needed? That seems like useless complexity=20 >>>>>> here. If it is needed, how does the verifier check that it's >>>>>> really a single-use? I don't see the point TBH. >>>>>> >>>>> >>>>> This text was driven by the statement in RFC 6487 (Section 3) >>>>> that says: >>>>> >>>>> The private key associated with an EE certificate is used to >>>>> sign a single RPKI signed object, i.e., the EE certificate is >>>>> used to validate only one object. >>>>> >>>>> Step 1 in 3.2 is there so that this approach follows the above >>>>> directive on the use of the RPKI infrastructure/certificates. >>>> >>>> Well... sure. But what is the benefit here? IIRC that was >>> >>> I *think* the benefit is supposed to be compliance with the RPKI >>> approach... >>> >>>> something related to making more fine-grained revocation possible >>>> or something which doesn't seem that useful here since a verifier >>>> will likely already have processed stuff already or am I mixed >>>> up? >>> >>> I don't think you are mixed up, but I will let others in SIDR chime >>> in=E2=80=A6 >> >> There was at one point in the history of resource certificates the >> idea that EE certs could be used multiple times. (EE certs even had >> their own manifests!) >> >> The signed object definition encapsulated the EE cert used to verify >> the signature. That revocation of the signed object could be >> accomplished by revoking the EE cert. Which meant that the EE cert >> should be used just to sign that one object, as Stephen says. >> (otherwise chaos ensues) >> >> As the only defined use of EE certs at the time of the publication of >> 6487 was the use to verify signed objects, the text about EE certs >> was reduced to just that necessary to support the single-use. >> >> This is different. The validity of the rpsl object is not tied to >> the validity of the EE cert. The comments from the wg were that this >> draft should talk about the syntax of the new attribute, not the >> authorization/semantics. So revocation of the EE cert in this case >> would/might not have the effect of revoking the rpsl object. I >> personally don=E2=80=99t think it likely that it ever will, but that=E2= =80=99s IMHO >> only. >> >> So it is a moot question as to whether the single-use is a part of >> =E2=80=9Cthe RPKI approach=E2=80=9D for this rpsl-sig use. >=20 > But that means that there is no reason to include the requirement > here then or am I missing something? Deleting that "step" in the > signing process would seem like a good idea so. (Assuming that > current implementers, if any, are fine with that.) As one implementer, I have no problem dropping this step. There is nothing in my RPSL code that enforces this (it is a function of the RPKI EE cert usage). >=20 >> >>> >>>> >>>> If there's no benefit, it seems like that adds a bunch of CA code >>>> just for fun (or "compliance" maybe;-) >> >> curious: how would this single-use requirement add anything to the CA >> code? If the requirement is in 6487, the CA code would already have >> the checks. I ask only because I might be missing something. >=20 > What I was trying to say was that requiring signers of this to > include all the CA code is the problem/oddity, esp if there's no > real benefit. >=20 > So the single-use thing doesn't add to the CA code, it adds a > need for the CA code in the wrong place. >=20 > And I guess if the spec says "once only" then I can well imagine > some poor verifier implementer keeping some kind of cache and > checking it'd not seen a signature before or something like that. > And that'd also be kinda pointless code too I think. I certainly don't do any type of checking at the verification step. Regards, Brian --vD4gFu2gpsqOMCAgHSVAHxPccHq7oQE5p-- --mVM4Q03keGclJonLXu3l8hBMh9pAcj5Ix Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXPa2MAAoJEBOZRqCi7goqE50H/ibURaLfrScxCOEn3Nk/hNXw NRGciDJHdCknUBNndPjJvJEqZBXkFRrJT2cso7RRRAXE2gNtYesvZPQf1pBe0aIs 6KQQ+OpNbCXkIkcX7BHX7X6If4YTnCK0ckiVWDVsT7xhP9IwzmYoy+qxhNc/7hcS UXJAopow26ra+NvK+i6tTS/XPg0rc/t7/OgXfZpAYNab4eKVfbsinDKvgv6zukeA HmfkIx9aSrfOhD0zFIyOPd48aRs0hi1z6JNBD17wFjI3J8ecv4O8DMXgWicw1ZP2 toKcT1D8GNZQwIpDa/zyBApSqu4LhoiBN3g7MAFfBrIRO3aohcACLDlA1e2yKcc= =zJ5W -----END PGP SIGNATURE----- --mVM4Q03keGclJonLXu3l8hBMh9pAcj5Ix-- From nobody Thu May 19 05:18:29 2016 Return-Path: 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 D543112DA0A; Thu, 19 May 2016 05:18: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, 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 Nhze2NisfQvW; Thu, 19 May 2016 05:18:22 -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 97FE612DA25; Thu, 19 May 2016 05:18:18 -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 87D19880E4; Thu, 19 May 2016 05:18:18 -0700 (PDT) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8D76C328081A; Thu, 19 May 2016 05:18:17 -0700 (PDT) To: Stephen Farrell , Sandra Murphy References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> <573CDD5A.4030206@cs.tcd.ie> <087861c3-d506-2ab8-0ecb-df09dc293678@innovationslab.net> From: Brian Haberman Message-ID: Date: Thu, 19 May 2016 08:18:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <087861c3-d506-2ab8-0ecb-df09dc293678@innovationslab.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0ON6KIp5IDPrkFQPUaAFlUEH6VBngQ0oR" Archived-At: Cc: sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:18:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0ON6KIp5IDPrkFQPUaAFlUEH6VBngQ0oR Content-Type: multipart/mixed; boundary="2gvvrMtC42ivtH6nAja22R1J9ObrQsPf1" From: Brian Haberman To: Stephen Farrell , Sandra Murphy Cc: draft-ietf-sidr-rpsl-sig@ietf.org, sidr-chairs@ietf.org, The IESG , sidr@ietf.org Message-ID: Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) References: <20160518155109.14693.29705.idtracker@ietfa.amsl.com> <7398a12b-5f01-275f-7dc6-178c6b611891@innovationslab.net> <573C93CD.4040901@cs.tcd.ie> <2e4e9c39-06a9-43ea-eee7-1c0a0a67ad22@innovationslab.net> <18A984F0-BEAE-4B5D-99EB-90BA79249C49@tislabs.com> <573CDD5A.4030206@cs.tcd.ie> <087861c3-d506-2ab8-0ecb-df09dc293678@innovationslab.net> In-Reply-To: <087861c3-d506-2ab8-0ecb-df09dc293678@innovationslab.net> --2gvvrMtC42ivtH6nAja22R1J9ObrQsPf1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One further point... Dropping step 1 in section 3.2 is one part of this change. I think that the fourth bullet in section 5 can be dropped as well. Thoughts? Regards, Brian On 5/19/16 8:11 AM, Brian Haberman wrote: > Hiya Stephen, >=20 > On 5/18/16 5:23 PM, Stephen Farrell wrote: >> >> Hi Sandy, >> >> On 18/05/16 22:12, Sandra Murphy wrote: >>> comments inline. speaking as a regular ol=E2=80=99 wg member >>> >>> On May 18, 2016, at 12:20 PM, Brian Haberman >>> wrote: >>> >>>> Hiya Stephen, >>>> >>>> On 5/18/16 12:09 PM, Stephen Farrell wrote: >>>>> >>>>> Hiya, >>>>> >>>>> On 18/05/16 17:06, Brian Haberman wrote: >>>>>> Hiya Stephen, >>>>>> >>>>>> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>>>>>> Stephen Farrell has entered the following ballot position >>>>>>> for draft-ietf-sidr-rpsl-sig-11: Discuss >>>>>>> >>>>>>> When responding, please keep the subject line intact and >>>>>>> reply to all email addresses included in the To and CC lines. >>>>>>> (Feel free to cut this introductory paragraph, however.) >>>>>>> >>>>>>> >>>>>>> Please refer to >>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>>>>> more information about IESG DISCUSS and COMMENT positions. >>>>>>> >>>>>>> >>>>>>> The document, along with other ballot positions, can be found >>>>>>> here:=20 >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----------------------------------------------------------------= ----- >>>>>>> >>>>>>> >> DISCUSS: >>>>>>> -----------------------------------------------------------------= ----- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> I'd like to check one thing - this may be needed for strict >>>>>>> compliance with RPKI thing but it seems kinda weird to also=20 >>>>>>> impose that here, but anyway... >>>>>>> >>>>>>> Is 3.2 step 1 needed? That seems like useless complexity=20 >>>>>>> here. If it is needed, how does the verifier check that it's >>>>>>> really a single-use? I don't see the point TBH. >>>>>>> >>>>>> >>>>>> This text was driven by the statement in RFC 6487 (Section 3) >>>>>> that says: >>>>>> >>>>>> The private key associated with an EE certificate is used to >>>>>> sign a single RPKI signed object, i.e., the EE certificate is >>>>>> used to validate only one object. >>>>>> >>>>>> Step 1 in 3.2 is there so that this approach follows the above >>>>>> directive on the use of the RPKI infrastructure/certificates. >>>>> >>>>> Well... sure. But what is the benefit here? IIRC that was >>>> >>>> I *think* the benefit is supposed to be compliance with the RPKI >>>> approach... >>>> >>>>> something related to making more fine-grained revocation possible >>>>> or something which doesn't seem that useful here since a verifier >>>>> will likely already have processed stuff already or am I mixed >>>>> up? >>>> >>>> I don't think you are mixed up, but I will let others in SIDR chime >>>> in=E2=80=A6 >>> >>> There was at one point in the history of resource certificates the >>> idea that EE certs could be used multiple times. (EE certs even had >>> their own manifests!) >>> >>> The signed object definition encapsulated the EE cert used to verify >>> the signature. That revocation of the signed object could be >>> accomplished by revoking the EE cert. Which meant that the EE cert >>> should be used just to sign that one object, as Stephen says. >>> (otherwise chaos ensues) >>> >>> As the only defined use of EE certs at the time of the publication of= >>> 6487 was the use to verify signed objects, the text about EE certs >>> was reduced to just that necessary to support the single-use. >>> >>> This is different. The validity of the rpsl object is not tied to >>> the validity of the EE cert. The comments from the wg were that this= >>> draft should talk about the syntax of the new attribute, not the >>> authorization/semantics. So revocation of the EE cert in this case >>> would/might not have the effect of revoking the rpsl object. I >>> personally don=E2=80=99t think it likely that it ever will, but that=E2= =80=99s IMHO >>> only. >>> >>> So it is a moot question as to whether the single-use is a part of >>> =E2=80=9Cthe RPKI approach=E2=80=9D for this rpsl-sig use. >> >> But that means that there is no reason to include the requirement >> here then or am I missing something? Deleting that "step" in the >> signing process would seem like a good idea so. (Assuming that >> current implementers, if any, are fine with that.) >=20 > As one implementer, I have no problem dropping this step. There is > nothing in my RPSL code that enforces this (it is a function of the RPK= I > EE cert usage). >=20 >> >>> >>>> >>>>> >>>>> If there's no benefit, it seems like that adds a bunch of CA code >>>>> just for fun (or "compliance" maybe;-) >>> >>> curious: how would this single-use requirement add anything to the CA= >>> code? If the requirement is in 6487, the CA code would already have >>> the checks. I ask only because I might be missing something. >> >> What I was trying to say was that requiring signers of this to >> include all the CA code is the problem/oddity, esp if there's no >> real benefit. >> >> So the single-use thing doesn't add to the CA code, it adds a >> need for the CA code in the wrong place. >> >> And I guess if the spec says "once only" then I can well imagine >> some poor verifier implementer keeping some kind of cache and >> checking it'd not seen a signature before or something like that. >> And that'd also be kinda pointless code too I think. >=20 > I certainly don't do any type of checking at the verification step. >=20 > Regards, > Brian >=20 --2gvvrMtC42ivtH6nAja22R1J9ObrQsPf1-- --0ON6KIp5IDPrkFQPUaAFlUEH6VBngQ0oR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXPa8IAAoJEBOZRqCi7goqCN0H/1FGsYPyu7b+jSadVvghCyMc QloTohbjnbiiNjZitSpxOG9vE5cc9shIHgrXhU6NuIpgSb5o6PqyRrmQXuKGsMIs hJ+JcIENkbSMdBwkdkRe6Q5/Go8SQWgLvZI7ZQ+bnKTy+8Illw8cszvyOBuDTiY0 i2nCgDJsd5btUNpq0oWnp8TWoptC8pw9uSta0e475BtlN8HLAo1AHnIyTvdrC09v aMZWeAoC/TA0BaFqNivBkBaFLtnQjbXG0BpFL6lz0DJKYRuMBvnK9MObjKpRs4EW wZyMs45yzpnzTUL5aWqCj0WUZX+SfOlMH2HPj+Al1Fq70T7SSFRaD5GQ2AgIvL8= =/9dX -----END PGP SIGNATURE----- --0ON6KIp5IDPrkFQPUaAFlUEH6VBngQ0oR-- From nobody Thu May 19 05:31:11 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F38112DA30; Thu, 19 May 2016 05:30:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519123044.17347.15442.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 05:30:44 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:30:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Securing RPSL Objects with RPKI Signatures Authors : Robert Kisteleki Brian Haberman Filename : draft-ietf-sidr-rpsl-sig-12.txt Pages : 15 Date : 2016-05-19 Abstract: This document describes a method to allow parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have Routing Policy System Security-based authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFC 2622 and RFC 4012 to add the signature attribute to supported RPSL objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpsl-sig-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 19 05:33:50 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D9312D0D9; Thu, 19 May 2016 05:33:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519123348.17368.83837.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 05:33:48 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sandy@tislabs.com Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpsl-sig-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:33:48 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-rpsl-sig-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks all for chatting about my discuss, I think the outcome is good. --- OLD COMMENTS below, I didn't check 'em, feel free to chat more or not, as you think best. - If you keep the potential for http(s) URIs then I think more text is needed in the security considerations but it looks like you're taking that out for now so I guess that's ok. - 2.1, I don't see why it's useful to allow variation in the fields of the signature attribute e.g. why "MAY" the version not be 1st? - 2.1, "t=" and "x=" any limits on precision here? (Non-)support for fractional seconds can be a source for non-interop if not. The "All times MUST be converted to" is also actually a little ambiguous as you don't say to do that before signing;-) - 2.1, "a=" did you want a lowercase "must" there? - Are steps 2 and 3 in 3.1 order-sensitive? I think you might sometimes need to do 2 after 3, or re-do 2 maybe or else leading whitspace could be an issue. Maybe say that sometimes you need to do step 2 >1 time? - 3.1, oops, an ambiguity - in "The following steps MUST be applied in order..." does "in order" mean "in the order below" or "so as to"? I assume the latter. - 3.1: In general I think you'd be better if you pointed at specific bits of text in all the RFCs mentioned in 3.1 - it's maybe easy to get wrong otherwise, esp. if we don't yet have >1 implementation. - 3.1, step 6: names are all ASCII right? just checking - 3.2, step 1 - given 3.3 step 2, you're missing a step to "publish the cert" at the c= location as well. From nobody Thu May 19 10:35:10 2016 Return-Path: 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 044A812DB2B for ; Thu, 19 May 2016 10:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 4eXao9HKW2YJ for ; Thu, 19 May 2016 10:35:07 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B09D12DB2C for ; Thu, 19 May 2016 10:34:58 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 6E73028B0043 for ; Thu, 19 May 2016 13:34:57 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 65CBC1F8055; Thu, 19 May 2016 13:34:57 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8FE6B775-BBEA-45F9-990B-BEB16BC39DC8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy Date: Thu, 19 May 2016 13:34:38 -0400 Message-Id: <339F3887-BBD5-4546-9DEF-0CF9423FA9D1@tislabs.com> References: To: sidr X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-rpsl-sig-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:35:09 -0000 --Apple-Mail=_8FE6B775-BBEA-45F9-990B-BEB16BC39DC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks to everyone for the energetic work in the last couple of weeks, = the last few days in particular. The draft has passed the IESG. Congratulations to the authors in = particular! =97Sandy, speaking as wg co-chair Begin forwarded message: > Resent-From: > From: "Alvaro Retana (aretana)" > Subject: Re: New Version Notification for = draft-ietf-sidr-rpsl-sig-12.txt > Date: May 19, 2016 at 10:38:29 AM EDT > Resent-To: morrowc@ops-netman.net, sandy@tislabs.com > To: Brian Haberman > Cc: "sidr-chairs@ietf.org" >=20 >=20 > On 5/19/16, 7:31 AM, "iesg on behalf of Brian Haberman" > wrote: >=20 > Brian: >=20 > Hi! We just finished the Telechat and approved this document. :-) >=20 > Thanks for the work! >=20 > Alvaro. >=20 >> This version contains all the changes to address the DISCUSS = points >> from Stephen, Terry, and Alexey. Please let me know if I missed any = of >> them. >>=20 --Apple-Mail=_8FE6B775-BBEA-45F9-990B-BEB16BC39DC8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXPfk/AAoJEHplpQeet0IZ9X8P/RbVkHmI8vZqExGZduicGV85 5/f42mtZ3StTOnddhpb3h6ZPeNxegy0UrjyTg5LTt2xEV6IkmiUpFD74+3SnUw5L cRD3jrGG2XIr/3YItl6PnCZpeW9oy6BpAqTv86YJO0c12K9PAjeuw6DSwlnePic5 6WKdurum66lRciA9fNVKmZlvQ0JasITbMeF5HEsLykTFJwcJ8L+tQMUhE2Ve1EPz qgmSdMNhoONcQ9bFP0B1Iri67+iTImrLNAyC3qbRTRXienW9z13+jI+ucTLNH3bC /0Fd1IhLaCBc13APPm9wkrUdBC+7i8a+xcs57lvwqmiMd4J2HVZQ1FJPB2E4e/AB YiELFLb+oJmsqeHW0xchEPdvQnnaG8f/FnK2XM8NpW00vrpufENYzeoHOUfqLSPR /T+25QVjrTsfdWKX1eeAgwpHD/P34FViucgrDm1UmHMxsVSr4ssYZ/MSuKQRhAnF hlUIxXhqso8dzaGKpM+e52Kiqw74U8LJsLU4qWrlxm+rfhjyG7dune5xM97zi3uy lF824KK8XZ7Ui+o2vasIL56xJcRUTed6AwQ1vwlUkEVF+EWln/epDULqRyL9tEB5 pC/QLYnTHYxVwRC4asSS5IKlO/yRJ0Vpwq98rfR+OdCWFehOrcAgh/teyMKjFDVj y3JNRjeEjblaRExrhwGh =a6RF -----END PGP SIGNATURE----- --Apple-Mail=_8FE6B775-BBEA-45F9-990B-BEB16BC39DC8-- From nobody Thu May 19 16:45:59 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E9412B04E; Thu, 19 May 2016 16:45:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160519234558.15425.21859.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 16:45:58 -0700 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6485bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Last Call: (The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 23:45:59 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-06-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. Downref: Normative references are made to 3 Informational documents: RFC2986, RFC3447 and RFC6480. RFC2986 and RFC3447 have been previously approved by the community (https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry). RFC2986 and RFC6480 were also Downrefs in RFC6485, which this document obsoletes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri May 20 04:32:57 2016 Return-Path: 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 38FAC12D894; Fri, 20 May 2016 04:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 cUJZpwunJ2YC; Fri, 20 May 2016 04:32:44 -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 A667E12D831; Fri, 20 May 2016 04:32:44 -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 ) id 1b3ifY-00082d-Ax; Fri, 20 May 2016 13:32:41 +0200 Received: from gibbon.ripe.net ([193.0.1.206] helo=[127.0.0.1]) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1b3ifY-0005v9-5T; Fri, 20 May 2016 13:32:40 +0200 To: George Michaelson References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> From: Robert Kisteleki Organization: RIPE NCC Message-ID: <9e0601f1-92f7-105b-57c1-c95d2fad660c@ripe.net> Date: Fri, 20 May 2016 13:32:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ---------- X-RIPE-Spam-Report: Spam Total Points: -10.8 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 -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274734bc57264d5e4e7cf989173833f93a2 Archived-At: Cc: "Sandra L. Murphy" , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-rpsl-sig@ietf.org, "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 11:32:49 -0000 Chiming it late... On 2016-05-19 0:39, George Michaelson wrote: > I would rather the sigs were signed by ee certs which were in the > blob, than have to make an external reference and I would rather we > varied the compliance needs to remove a pointless external ref. > > If there has to be a ref, I think making it mandated to a specific > scheme is over specifying, especially in a context where we might > begin to understand *where you get cryptographic materials from is > less important than proving who said them*. > > Rsync is a bad fit. for the actual signing cert, Inline is better. It > can refer to whatever chain it likes. > > -G In the good ol' days a reference was put in because while the signature itself is relatively small, including the full EE cert would bloat the whole RPSL object to potentially multiple times its original size -- and for those who don't care about signatures this is a huge overhead. Furthermore, if one would reuse EE certs in multiple signatures (I don't see why that would be prohibited -- for example if I want to sign multiple objects at the same time), then this method makes even more sense. Then the whole back-and-forth started about whether it should be rsync or http(s) and now perhaps it's neither. It feels like we're going around in circles here :) Robert From nobody Fri May 20 05:53:21 2016 Return-Path: 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 1F43E12D90E for ; Fri, 20 May 2016 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 cAURR7_3KlJq for ; Fri, 20 May 2016 05:53:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EB612B03D for ; Fri, 20 May 2016 05:53:18 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:36851 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1b3jvV-000Dix-Vt for sidr@ietf.org; Fri, 20 May 2016 08:53:14 -0400 From: Stephen Kent To: sidr@ietf.org References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> Message-ID: <573F08B9.2010901@bbn.com> Date: Fri, 20 May 2016 08:53:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 12:53:20 -0000 George, I agree that it's more convenient to have the EE cert close to the RPSL data being verified. Just so long as RPs use the RPKI to acquire the cert path info, revocation status info, etc. Steve From nobody Fri May 20 05:53:24 2016 Return-Path: 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 99EF812D916 for ; Fri, 20 May 2016 05:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 42c3Lc81L0J9 for ; Fri, 20 May 2016 05:53:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BEEC12B03D for ; Fri, 20 May 2016 05:53:21 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:36852 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1b3jvc-000Dj3-9I for sidr@ietf.org; Fri, 20 May 2016 08:53:20 -0400 From: Stephen Kent To: sidr@ietf.org References: <20160519123348.17368.83837.idtracker@ietfa.amsl.com> Message-ID: <573F08C0.1020202@bbn.com> Date: Fri, 20 May 2016 08:53:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519123348.17368.83837.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpsl-sig-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 12:53:23 -0000 Stephen, et al., A couple of observations about the topic of certs used to verify RPSL sigs: - the title of the I-D says that it relies upon the RPKI, and, as currently written, it mandates use of RPKI certs. So, using certs from a different PKI would require a re-write. Also, the security of the system would be reduced if other certs were employed, wrt verification of assertions about address space and ASN holdings. So, I don't think it's appropriate to suggest alternative PKIs. I also note that the text on page 3 that says "equivalent functionality can be achieved" using an alternative PKI is questionable. Merely having 3379 extensions in a cert does not mean that all of the other security-relevant elements of the RPKI accrue. (Also, there is a typo: certificate authority" -> "certification authority") - if one is using RPKI EE certs, as currently mandated, then the single use requirement (which is imposed on CAs, but RPs are not required to verify) applies. Deliberate re-use of a cert would mean that the CA violated the cert policy, and thus the cert ought not contain the RPKI policy ID, etc. Also, the Security Considerations section of the I-D refers to 6487, which is appropriate only if we're discussing RPKI certs. - The phrase "money-in-the-middle" is cute, but Randy's terminology is not widely adopted. I suggest using the more conventional terminology that a wider range of readers will recognize. Steve From nobody Fri May 20 07:18:30 2016 Return-Path: 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 3CF1D12D9A8; Fri, 20 May 2016 07:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 ux95hNTMyeo5; Fri, 20 May 2016 07:18:26 -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 EA27812D9A6; Fri, 20 May 2016 07:18:25 -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 ) id 1b3lFt-0006vB-Fi; Fri, 20 May 2016 16:18:23 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-30.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1b3lFt-0000Ea-7b; Fri, 20 May 2016 16:18:21 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <9e0601f1-92f7-105b-57c1-c95d2fad660c@ripe.net> Date: Fri, 20 May 2016 16:18:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518033754.24796.52937.idtracker@ietfa.amsl.com> <35AEF9F7-FFAD-470B-9D0D-1D7BE7C7FE90@ripe.net> <9e0601f1-92f7-105b-57c1-c95d2fad660c@ripe.net> To: Robert Kisteleki X-Mailer: Apple Mail (2.3124) 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: 784d7acfe6559f2a0b602ec6519a07197f349b0dd4566e318ff29e5a7ada2e00 Archived-At: Cc: draft-ietf-sidr-rpsl-sig@ietf.org, "Sandra L. Murphy" , sidr-chairs@ietf.org, The IESG , "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:18:29 -0000 Hi Robert, all, > On 20 May 2016, at 13:32, Robert Kisteleki wrote: >=20 > Chiming it late... >=20 > On 2016-05-19 0:39, George Michaelson wrote: >> I would rather the sigs were signed by ee certs which were in the >> blob, than have to make an external reference and I would rather we >> varied the compliance needs to remove a pointless external ref. >>=20 >> If there has to be a ref, I think making it mandated to a specific >> scheme is over specifying, especially in a context where we might >> begin to understand *where you get cryptographic materials from is >> less important than proving who said them*. >>=20 >> Rsync is a bad fit. for the actual signing cert, Inline is better. It >> can refer to whatever chain it likes. >>=20 >> -G >=20 > In the good ol' days a reference was put in because while the = signature > itself is relatively small, including the full EE cert would bloat the = whole > RPSL object to potentially multiple times its original size -- and for = those > who don't care about signatures this is a huge overhead. Furthermore, = if one > would reuse EE certs in multiple signatures (I don't see why that = would be > prohibited -- for example if I want to sign multiple objects at the = same > time), then this method makes even more sense. Let me attempt a different angle. I think a more fundamental question is = whether we would expect this EE certificate a) to appear in the normal = RPKI repository as one of the signed products of a CA, and appear on the = manifest - or b) to be an embedded certificate, or c) that it can be a = detached EE certificate that lives elsewhere, but is validated against a = signing CA cert and CRL that do live in the 'normal' RPKI repository. Currently looking at the document it's not clear to me whether 'a' or = 'c' is intended. My preference however is 'b'. if a) in the normal RPKI Then I think we should stick to rsync as it's currently required for all = RPKI certificates. Even if using RRDP, we still have the rsync URIs as a = hint in the XML so we can find the certificate. If this is the way, then there are some amendments needed to profile and = repository standards - as discussed in the thread - let me not repeat = here. Currently deployed RPs *will* choke on this. So this option does = not have my preference. if b) embedded I prefer this approach because it makes it easier to specify the = certificate and define validation in the RPSL-SIG document, and it has = no impact on RPKI deployment. If you like I can suggest text.. And if you want to multi-use and fate-share (indeed I think this is = generally an easy way to shoot in one's own foot, and don't see = optimisation by doing this), you can just embed the same certificate. As = I stated in my response to George I am not convinced that the size is = problematic. I think we can filter this if we must. In response to Stephen's suggestion to use another attribute for the = certificate: I prefer not to. The reason is that we would have to = introduce two new optional attributes that need to appear in = conjunction, and I believe this makes it unnecessarily difficult to = implement RPSL object validation and attribute filtering. The value of = the 'signature' attribute is well-defined and needs to be parsed anyway, = so adding an element to contain the certificate does not seem = problematic to me. if c) third location I believe this is the worst option. Having random third locations to = retrieve the EE certificates over http(s) or rsync, different from the = RPKI repository itself and from where the RPSL objects are retrieved = introduces a lot of overhead for both RPs and publishers, and introduces = a potential for failure to retrieve. > Then the whole back-and-forth started about whether it should be rsync = or > http(s) and now perhaps it's neither. It feels like we're going around = in > circles here :) Yep, you have my sympathy and I am sorry for not engaging more actively = earlier. We found this and the concerns raised by Tom when we worked on an = inter-operating proof of concept implementation recently. On a positive = note, as a general concept we found this works. It's really about where = to find EE cert, and how to relate it to a CA certificate and CRL in the = existing RPKI. >=20 > Robert >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri May 20 11:33:21 2016 Return-Path: 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 9AA7512D56E for ; Fri, 20 May 2016 11:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 KM3TjUPyHmL4 for ; Fri, 20 May 2016 11:33:18 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B78012D566 for ; Fri, 20 May 2016 11:33:18 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 5D1AE28B0041 for ; Fri, 20 May 2016 14:33:17 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 477231F8055; Fri, 20 May 2016 14:33:17 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_38DD0DAC-E6EE-4E40-BA07-70A4B7868C60"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Date: Fri, 20 May 2016 14:32:40 -0400 Message-Id: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> To: sidr X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 18:33:19 -0000 --Apple-Mail=_38DD0DAC-E6EE-4E40-BA07-70A4B7868C60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The adoption discussion showed consensus that the wg wants to adopt this = work. The authors should submit a draft using the usual wg draft naming = convention: draft-ietf-sidr-yourtitlehere.txt =97Sandy, speaking as one of the wg co-chairs (Actually, the adoption discussion was more energetic and productive = than I remember seeing in a long time.) On Apr 27, 2016, at 8:11 AM, Sandra Murphy wrote: > The authors have requested working group adoption for = draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin = Validation Results from a Route-Server to Peers=94. >=20 > This message starts an adoption call that will end in two weeks on 11 = May 2016. >=20 > Please respond on the list to say whether you support adoption of this = work as a working group work item AND whether you will participate in = the discussion. >=20 > Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >=20 > The draft is available at = https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 >=20 > =97Sandy, speaking as one of the wg co-chairs >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_38DD0DAC-E6EE-4E40-BA07-70A4B7868C60 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXP1hqAAoJEHplpQeet0IZmWwP/2bb+7ZdYfGuSeMfgPS6cCiA BzIuGkumKje5S0ArqfvYGNSYVFY366/vHd0y5eJPMnEWdgOQlb03FDdgpmJutujm QQzysa8TzsMAtuk3p+FwzK1CREqFJe9jpWJd7WqIgHknO92SDKYaI8wznBo1voZt pM8YubVViTKqcp5h9+w/N3WumjViZrx/OrmNg0ZlUU9HhGZlK+zJ7ysQZcXSB8O7 bdJ0zfyrhs5cE5yYvn+FWNJrH8peEMi32A0He0kUQuICDjrK+lQ6yAmLrwsnh3E6 cmSD497K5SwKKAea9Kg/404qYr1I1ggATOmQX64XUpBMzCdUX1vdhQOtXRcWKW3A r7PDxbIvevSOp3Jbx+cwMmKbsU8XLnTH1XDU/2+xF0qYIoM9Tat7x3UopAMAEsqR 8r6Jx3HC+ZmItkt21CBKFdRWOW6/LWDkeySwpkcQorin7iE8CyhgXogZgMzLMuKs eYH1i+fFepmQpXsMImVyZClEb+aX7mz0IeDfpNJ9GnR61J0Ic1cnm6L6hxdXXTLO GT/oqP21ahNhhKcGrQC8ac2APwJFVYXS1g/x53/3Q+jtQOjlYOV7HPNzwHKDyzUG Doid6o9xWrogTOMmUMqtyoF3zuaU4Sl458Wk1Ay1sAmNRmfWgkM/3ulkojoRjNl5 HLARbo8g1RBHZBWMsMKN =+/OP -----END PGP SIGNATURE----- --Apple-Mail=_38DD0DAC-E6EE-4E40-BA07-70A4B7868C60-- From nobody Mon May 23 09:15:42 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666F12D9CD; Mon, 23 May 2016 09:15:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523161540.20860.15861.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 09:15:40 -0700 Archived-At: Cc: draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org, The IESG , sandy@tislabs.com, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'Securing RPSL Objects with RPKI Signatures' to Proposed Standard (draft-ietf-sidr-rpsl-sig-12.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 16:15:41 -0000 The IESG has approved the following document: - 'Securing RPSL Objects with RPKI Signatures' (draft-ietf-sidr-rpsl-sig-12.txt) as Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ Technical Summary This document describes a method to allow parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have Routing Policy System Security-based authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. Working Group Summary This document has been in the working group for a long time; periodic interest polls have always been positive. Document Quality Yes, IRR implementations exist. The reviews so far have been thorough. Personnel Shepherd: Sandra Murphy Responsible AD: Alvaro Retana From nobody Tue May 24 21:10:01 2016 Return-Path: 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 5451B12D5D8; Tue, 24 May 2016 21:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Td5U3heDv0NP; Tue, 24 May 2016 21:09:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF0A12D5C3; Tue, 24 May 2016 21:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10317; q=dns/txt; s=iport; t=1464149396; x=1465358996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zTSFduqyn6KUa2jPppgVE59A46qxQl35COjBF5XrucA=; b=S+2siMHzEcjhb6l1uXK+K0U6GOCJq/nABHtq6t2o5ozk6YxGTZcGPtJX MhYEitLj0s6+fILPw8lrLl1cVofH/Auim+tJJN5TtVLm5E52NhTOlQf0f VgbdZB9IMC+kkEeRscwceke5v7ypTvbVyynfBIKZ53E4AuUg+YCqdv70C 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxAgBmJEVX/5NdJa1bgzeBUwa5fgENg?= =?us-ascii?q?XaGEQKBODgUAQEBAQEBAWUnhEMBAQQ6Mg0QAgEIDgoeEDIlAgQOBRkCiBTESQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEehAmCHoRMihkBBIgGizGFAAGOH4FpjTOGM4kYA?= =?us-ascii?q?R4BAUKDbW6JCH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,362,1459814400"; d="scan'208";a="277404124" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 04:09:55 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4P49sMf005119 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 04:09:55 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 May 2016 23:09:54 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 24 May 2016 23:09:55 -0500 From: "Alvaro Retana (aretana)" To: Rob Austein Thread-Topic: AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 Thread-Index: AQHRnPRan3y40yRdEkS30+qNsvqUUg== Date: Wed, 25 May 2016 04:09:54 +0000 Message-ID: References: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net> In-Reply-To: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 04:09:59 -0000 On 4/26/16, 6:58 PM, "Rob Austein" wrote: Rob: Hi! >At Sat, 23 Apr 2016 00:09:07 +0000, Alvaro Retana (aretana) wrote: >> >> * Section 1.2. (Changes from RFC 6810): "The protocol >> described in this document is largely compatible with >> [RFC6810]." What does "largely compatible" mean? It >> either is compatible or it isn't. > >It means that most of the code one needs to deal with version one is >the same as the code one needs to deal with version zero. Feel free >to suggest better text. When I think about protocol compatibility I think about on-the-wire behavior and packets, not about the implementation internals. NEW> The protocol described in this document should allow an implementation to largely reuse the code developed for version zero. However, I would prefer if the sentence was taken out completely. ... > >> * This document is marked as obsoleting rfc6810, but it >> mandates its use in section 7 ("...the cache MUST downgrade >> to protocol version 0 [RFC6810]..."). There are a couple >> of paths forward: >> >> * It seems to me that this document should simply be >> called "RPKI to Router Protocol version 1" and not >> change the status of rfc6810 - we can always declare >> version 0 historic later. >> >> * If you really want to obsolete version 0, then an >> alternative is to eliminate the normative language when >> it refers to it... For example, >> >> * OLD> "If a cache which supports version 1 receives a >> query from a router which specifies version 0, the >> cache MUST downgrade to protocol version 0 [RFC6810] >> or send a version 1 Error Report PDU with Error Code >> 4 ("Unsupported Protocol Version") and terminate the >> connection." >> >> * NEW> "If a cache which supports version 1 receives a >> query from a router which specifies version 0, the >> cache SHOULD send a version 1 Error Report PDU with >> Error Code 4 ("Unsupported Protocol Version") and >> terminate the connection." > >The intent is to deprecate version zero, because it lacks features we >think are important. But version zero is already in the field and we >have no control over how long it will take to upgrade all existing >copies. So we have to specify how versions zero and one are intended >to interoperate. I don't know how to specify that without normative >references to the older version. If you want to deprecate version zero, then Obsoleting rfc6810 is ok. What is not ok is mandating its use at the same time. I'm thinking that we could get away with removing Section 7 completely, and leaving the downgrade behavior as a "local implementation detail" -- see below: I'm including comments on Section 7, and an optional new subsection. Notes_On_7 (my comments with [A]> 7. Protocol Version Negotiation A router MUST start each transport connection by issuing either a Reset Query or a Serial Query. This query will tell the cache which version of this protocol the router implements. [A] This text (above) is in conflict with Section 8.1. (Start or Restart) which reads: "When a transport connection is first established, the router MAY send a Reset Query...Alternatively...it MAY start with a Serial Query..." To match the behavior in Section 7, here's a suggestion for alternate text (for 8.1). OLD> When a transport connection is first established, the router MAY send a Reset Query and the cache responds with a data sequence of all data it contains. Alternatively, if the router has significant unexpired data from a broken session with the same cache, it MAY start with a Serial Query containing the Session ID from the previous session to ensure the Serial Numbers are commensurate. NEW> When a transport connection is first established, the router MUST send a Reset Query and the cache responds with a data sequence of all data it contains, or a Serial Query. The Serial Query can be used if the router has significant unexpired data from a broken session with the same cache; in this case the Serial Query containing the Session ID from the previous session to ensure the Serial Numbers are commensurate. [A] BTW, a couple of paragraphs later the text goes back to saying that "The router MUST send either a Reset Query or a Serial Query..." I think this text would now be redundant and can be deleted. If a cache which supports version 1 receives a query from a router which specifies version 0, the cache MUST downgrade to protocol version 0 [RFC6810] or send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection. [A] The behavior of sending the Error PDU is expected if the cache doesn't support anything else. In the case of the cache supporting both, it can just directly downgrade (as a local decision) -- see some suggested text below. If a router which supports version 1 sends a query to a cache which only supports version 0, one of two things will happen. 1. The cache may terminate the connection, perhaps with a version 0 Error Report PDU. In this case the router MAY retry the connection using protocol version 0. 2. The cache may reply with a version 0 response. In this case the router MUST either downgrade to version 0 or terminate the connection. [A] In this case again, the behavior of the router can be a local decision: if a version 0 response (including an Error PDU) is received, then downgrade -- again, see suggested text below. In any of the downgraded combinations above, the new features of version 1 will not be available. If either party receives a PDU containing an unrecognized Protocol Version (neither 0 nor 1) during this negotiation, it MUST either downgrade to a known version or terminate the connection, with an Error Report PDU unless the received PDU is itself an Error Report PDU. [A] Both versions react the same way to an unrecognized version...so no need to repeat. The router MUST ignore any Serial Notify PDUs it might receive from the cache during this initial start-up period, regardless of the Protocol Version field in the Serial Notify PDU. Since Session ID and Serial Number values are specific to a particular protocol version, the values in the notification are not useful to the router. Even if these values were meaningful, the only effect that processing the notification would have would be to trigger exactly the same Reset Query or Serial Query that the router has already sent as part of the not-yet-complete version negotiation process, so there is nothing to be gained by processing notifications until version negotiation completes. [A] This text (above) is in conflict with Section 5.2. (Serial Notify), which reads: "If the router receives a Serial Notify PDU during the initial start-up period...the router SHOULD simply ignore the Serial Notify PDU..." Solution: update 5.2 with a "MUST" -- according to the explanation above, there's no real value in listening (which would not make it a "SHOULD"). [A] Section 5.2 also says: "See Section 7 for details." Instead of that reference, you can include the additional text above (after the first sentence). Caches SHOULD NOT send Serial Notify PDUs before version negotiation completes. Note, however, that routers MUST handle such notifications (by ignoring them) for backwards compatibility with caches serving protocol version 0. [A] The text above is the corollary of the "MUST ignore" text before it (you can include it in 5.2)...and the second sentence is really redundant. Once the cache and router have agreed upon a Protocol Version via the negotiation process above, that version is stable for the life of the session. See Section 5.1 for a discussion of the interaction between Protocol Version and Session ID. If either party receives a PDU for a different Protocol Version once the above negotiation completes, that party MUST drop the session; unless the PDU containing the unexpected Protocol Version was itself an Error Report PDU, the party dropping the session SHOULD send an Error Report with an error code of 8 ("Unexpected Protocol Version"). [A] Add the exception (receiving an Error PDU) to the definition of error code 8 in Section 12. Given that it is in fact possible to find older versions in the field, you might want to include a Section calling that out. My suggestion is to create a new Section called "Deployment Considerations", include in it the current Section 11. (Deployment Scenarios) as a sub-section, and add a new sub-section called "Transition Considerations". Suggestion> 11.2 Transition Considerations This document Obsoletes version zero of this protocol [RFC6810]. The intent is to deprecate its use. However, version zero is already in the field and it is possible that deployments will encounter mixed scenarios, where a router or cache may only support version zero. It is also expected that during the transition period a cache or router that supports version one will also support version zero. The determination=20 that a peer (cache or router) only supports version zero is straight forward: a version zero PDU is received from them. In these cases, it is up to the local implementation, and policy, whether it might prefer to use version zero to establish the session, with the understanding that the new features of version one will not be available. One new comment: Section 12. (Error Codes) says that "Errors which are considered fatal SHOULD cause the session to be dropped." When is it ok not to drop the session? IOW, why not use a "MUST"? Thanks! Alvaro. From nobody Thu May 26 08:15:49 2016 Return-Path: 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 33F3C12D710 for ; Thu, 26 May 2016 08:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 B5T-3MlruV5C for ; Thu, 26 May 2016 08:15:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6A912D70A for ; Thu, 26 May 2016 08:15:46 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37574 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1b5x0k-000AeM-6L for sidr@ietf.org; Thu, 26 May 2016 11:15:46 -0400 From: Stephen Kent To: sidr@ietf.org References: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net> Message-ID: <57471323.6050704@bbn.com> Date: Thu, 26 May 2016 11:15:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:15:48 -0000 Alvaro, > ... >> It means that most of the code one needs to deal with version one is >> the same as the code one needs to deal with version zero. Feel free >> to suggest better text. > When I think about protocol compatibility I think about on-the-wire > behavior and packets, not about the implementation internals. I'm not sure what the phrase "on-the-wire behavior" means. Certainly it is not enough to agree on data formats, i.e., the format of data on the wire. There also must be consistent behavior by each end of a connection/session/ ... (in terms of externally-visible processing) of the agreed upon data format. Otherwise, the behavior of "compatible" implementations may vary significantly, and users will not see the versions as "compatible." I think your latter comments match my sense of "compatibility", but I just wanted to make sure we are on the same page. Steve From nobody Fri May 27 10:39:14 2016 Return-Path: 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 63F1712D6F3 for ; Fri, 27 May 2016 10:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 rRg8_ay6GL3c for ; Fri, 27 May 2016 10:39:11 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868E212D0F3 for ; Fri, 27 May 2016 10:39:11 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D14E928B0052; Fri, 27 May 2016 13:39:10 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id BC4121F8055; Fri, 27 May 2016 13:39:10 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2016 13:39:08 -0400 Message-Id: To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] draft-ietf-sidr-bgpsec-pki-profiles-16 and multiple use EE certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 17:39:12 -0000 The discussion of the draft-ietf-sidr-rpsl-sig draft with the IESG = brought the single-use language in RFC6487 into the discussion. The authors of the rpsl-sig pointed to the language in RFC6487 section = 3: The private key associated with an EE certificate is used to sign a single RPKI signed object, i.e., the EE certificate is used to validate only one object. While this language is not normative, this language could be taken as a = requirement. The working group and the IESG accepted removal of this = requirement for the EE certificates used in the rpsl-sig attributes. The same applies to the router certificates defined in = draft-ietf-bgpsec-pki-profiles-16. The chairs direct the authors to add the following to = draft-ietf-sidr-bgpsec-pki-profiles-16. 3.4 Router Certificates and Signing Functions in the RPKI As described in Section 1, the primary function of BGPsec router certificates in the RPKI is for use in the context of certification of Autonomous System (AS) paths in the Border Gateway Protocol Security protocol (BGPsec). The private key associated with a router EE certificate may be used = multiple times in generating signatures in multiple instances of the BGPsec_Path Attribute Signature Segments [ID.sidr-bgpsec-protocol] . I.e., the BGPsec router certificate is used to validate multiple = signatures. BGPsec router certificates are stored in the issuing CA's repository, where a repository following RFC6481 MUST use a .cer filename = extension for the certificate file. =97Sandy, speaking as one of the co-chairs=