From nobody Mon Aug 3 10:52:10 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE2C1B2D77; Mon, 3 Aug 2015 10:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham 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 XUYlNwGcxrCX; Mon, 3 Aug 2015 10:52:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7991B2D6D; Mon, 3 Aug 2015 10:52:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150803175200.22878.78494.idtracker@ietfa.amsl.com> Date: Mon, 03 Aug 2015 10:52:00 -0700 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6490-bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-rfc6490-bis-04: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 17:52:06 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-rfc6490-bis-04: 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-rfc6490-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just as a nit - there are at least a couple of places in this draft, that are unchanged from RFC 6490, that say "this document" or "this approach", which made more sense to me looking at RFC 6490 than at a document that will obsolete RFC 6490 (I didn't know where "this" was pointing). If anyone else finds that confusing, the authors might want to look at that. From nobody Mon Aug 3 13:16:37 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053021B30D6; Mon, 3 Aug 2015 13:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GtrtmKVI97nh; Mon, 3 Aug 2015 13:16:34 -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 B400B1B30C1; Mon, 3 Aug 2015 13:16:34 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B175228B0041; Mon, 3 Aug 2015 16:16:33 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 6DD1B1F8035; Mon, 3 Aug 2015 16:16:33 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E50274CF-4E2E-48E5-AE5F-3F2B4EA6C583"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Sandra Murphy In-Reply-To: <20150730155133.D18C719D848A@minas-ithil.hactrn.net> Date: Mon, 3 Aug 2015 16:16:22 -0400 Message-Id: <19AFB4E0-C337-4E81-83C7-087F7E1CA4B9@tislabs.com> References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com> <55B97546.3060200@bbn.com> <20150730155133.D18C719D848A@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr@ietf.org, ietf@ietf.org, Sandra Murphy Subject: Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 20:16:36 -0000 --Apple-Mail=_E50274CF-4E2E-48E5-AE5F-3F2B4EA6C583 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 30, 2015, at 11:51 AM, Rob Austein wrote: >=20 > I prefer Richard's option 2 (allow but do not require linebreaks), > which is what RFC 6490 RP implementations had to support anyway. >=20 Richard=92s option 2 allows insertion of line breaks in a TAL. Should we add a =93Relying parties MUST ignore line breaks/whitespace=94 = as well? Richard=92s message agrees that everyone=92s relying party code he=92s = looked at does that anyway. =97Sandy --Apple-Mail=_E50274CF-4E2E-48E5-AE5F-3F2B4EA6C583 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 iQIcBAEBCgAGBQJVv8whAAoJEHplpQeet0IZ+qEP/377zPmxMCPGQqFZ3nmfGjzZ vCEFP5+HjPFzmnCsuWSL5sqLSs0ItCdhs7OdrqBIoHl2cL9nO+yxu5YkxFBQDAS9 gwiM5asOtqtNVzgX/xr/0BVNz+uhTBVAYtj5xX3ZlJAeW+/ucPgqNgB/nj8vN0Af hkzHkXxrx8vGBvaL2oUTWkR/G+63/sa/arAXTQw1qOtRXKfO/zO1ZfZ2orPGz2D6 mhPTBSiONQfUYY5IgiOvpzzkXVN9Fk82aIq37nSpEP4mQh27aGhcZVoy+Me1VtJ7 +A3HTJiRuxMt+YBf5AC5y7AoXfNV62E2mjgNczhGMFY4SnnLEurhP3b0D/7eia83 SREGY6GUQsuw+GHrKpvpFu5YBS9BZ1+ZElz3Cuvw/TIBLTSnUL9i3OQkHiOSV+n5 VGveaBPpNrF9taRxKRQ7swRtsMB2uu1wd8Eg4YAav+qbkaCymo51KHEGRhMdxt12 IcothaiGwgwcTz0oB6eqiJWM7R0Zv1Eh8daJGXR/axZ4KPtX/H3HtR2mua5fzlYw BZs0aieFT68jA+r2e+WTPeovdBbHOlFw/gqY16ZfD2XTe0SAoC9Fm3TZftVc/ICG zUyDYikqGPWM/ZmrEELRwRFVUAIT+XNGFYhJ+d6eEslFCCUzzmIPqy0PsOhBfF+j 4Sl0v5H1bjlJ15d2kTEm =QoHM -----END PGP SIGNATURE----- --Apple-Mail=_E50274CF-4E2E-48E5-AE5F-3F2B4EA6C583-- From nobody Mon Aug 3 13:42:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DAD1B311A; Mon, 3 Aug 2015 13:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_71=0.6, J_CHICKENPOX_81=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 yNYAi2YtWKCt; Mon, 3 Aug 2015 13:42:42 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB471B3123; Mon, 3 Aug 2015 13:42:42 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id EDF1CB805; Mon, 3 Aug 2015 20:42:40 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id BEECF19E9585; Mon, 3 Aug 2015 16:42:23 -0400 (EDT) Date: Mon, 03 Aug 2015 16:42:23 -0400 From: Rob Austein To: sidr@ietf.org, ietf@ietf.org In-Reply-To: <19AFB4E0-C337-4E81-83C7-087F7E1CA4B9@tislabs.com> References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com> <55B97546.3060200@bbn.com> <20150730155133.D18C719D848A@minas-ithil.hactrn.net> <19AFB4E0-C337-4E81-83C7-087F7E1CA4B9@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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20150803204223.BEECF19E9585@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 20:42:43 -0000 At Mon, 3 Aug 2015 16:16:22 -0400, Sandra Murphy wrote: >=20 > On Jul 30, 2015, at 11:51 AM, Rob Austein wrote: > >=20 > > I prefer Richard's option 2 (allow but do not require linebreaks), > > which is what RFC 6490 RP implementations had to support anyway. >=20 > Richard?s option 2 allows insertion of line breaks in a TAL. >=20 > Should we add a ?Relying parties MUST ignore line breaks/whitespace? as w= ell? Writer being allowed to insert whitespace rather strongly implies that reader must cope with said whitespace, so seem unnecessary, but if saying this explicitly makes people feel better, sure, whatever. > Richard?s message agrees that everyone?s relying party code he?s > looked at does that anyway. Yep. From nobody Mon Aug 3 17:54:33 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19FE1B2A10; Mon, 3 Aug 2015 17:54:31 -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] autolearn=ham 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 QdlO62FI2UWo; Mon, 3 Aug 2015 17:54:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EA21B327D; Mon, 3 Aug 2015 17:54:29 -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.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804005429.3078.1219.idtracker@ietfa.amsl.com> Date: Mon, 03 Aug 2015 17:54:29 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:54:32 -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 Working Group of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol Authors : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-rfc6810-bis-05.txt Pages : 32 Date : 2015-08-03 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver validated prefix origin data and router keys to routers. This document describes version 1 of the rpki-rtr protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-05 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 Aug 3 18:09:44 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A261B3204 for ; Mon, 3 Aug 2015 18:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gVJ4vQl1cfL8 for ; Mon, 3 Aug 2015 18:09:41 -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 7818D1B31D3 for ; Mon, 3 Aug 2015 18:09:41 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3B6477A1C for ; Tue, 4 Aug 2015 01:09:39 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 62DA919EA7E5 for ; Mon, 3 Aug 2015 21:09:21 -0400 (EDT) Date: Mon, 03 Aug 2015 21:09:21 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20150804005429.3078.1219.idtracker@ietfa.amsl.com> References: <20150804005429.3078.1219.idtracker@ietfa.amsl.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: <20150804010921.62DA919EA7E5@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 01:09:43 -0000 One more rev to address issues raised in a post-WGLC review. At this point the authors are of the opinion that this document is ready to be sent to the IESG (or the Document Shepard writeup, or whatever the process voodoo is this year), but of course that decision is up to the WG chairs. From nobody Tue Aug 4 04:06:23 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E6C1B37A5 for ; Tue, 4 Aug 2015 04:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3bYAkZvd41Af for ; Tue, 4 Aug 2015 04:06:19 -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 0D7E71B37B2 for ; Tue, 4 Aug 2015 04:06:15 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 62EE928B003D for ; Tue, 4 Aug 2015 07:06:14 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3785C1F8035; Tue, 4 Aug 2015 07:06:14 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_76768088-71B0-4D51-B86B-FCA69329C602"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 4 Aug 2015 07:06:22 -0400 Message-Id: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com> To: sidr wg list 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] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 11:06:21 -0000 --Apple-Mail=_76768088-71B0-4D51-B86B-FCA69329C602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking as document shepherd. The IETF Last Call for draft-ietf-sidr-rfc6490-bis-04.txt ended on 23 = July 2015. One issue of substance arose - permitting or forbidding line breaks in = the base64 encoding of the trust anchor, and, if permitted, at what max = line length. I do not see wg consensus about exact resolution. Various options and various max line lengths have been suggested. = Existing implementations use various line lengths. More commenters, please. Preferences for Richard=92s option #2 (allow but do not mandate line = breaks) or for Richard=92s option #3 (mandate line breaks)? Note that = option #3 means we have to settle on a max line length. =97Sandy http://www.ietf.org/mail-archive/web/sidr/current/msg07142.html IETF = Last Call http://www.ietf.org/mail-archive/web/sidr/current/msg07164.html Richard = Hansen http://www.ietf.org/mail-archive/web/sidr/current/msg07165.html Tim = Bruijnzeels http://www.ietf.org/mail-archive/web/sidr/current/msg07200.html Richard = Hansen http://www.ietf.org/mail-archive/web/sidr/current/msg07201.html Rob = Austein http://www.ietf.org/mail-archive/web/sidr/current/msg07202.html David = Mandelberg http://www.ietf.org/mail-archive/web/ietf/current/msg94157.html Viktor = Dukhovni --Apple-Mail=_76768088-71B0-4D51-B86B-FCA69329C602 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 iQIcBAEBCgAGBQJVwJyzAAoJEHplpQeet0IZSLkP/2UN4z/GiYPErqyBowPQnEqk 5LpC2C6JU8UARE1CrYviqPz/9/H7+1SVEMu2tZoERMcKZCRqo2BoxKyMGGqejwtm zCiWpUCzAPjqlsL0SMuYRHqeiRuL+fNHQZyrBBY4SWGzf1YyHdYQh5oEIhB55hhf X9zF1CgtPwiMBi/Z0EchvWJyyAwKiDbN6OVFLsab033qJ48wmmRaPZyAQA6Iy8Go kZIyPxA8LDcsKbK9PrStWZt18jo/UQsIUNKsDKi1JvJ6qVdR15C9EukfNJHkbjfh 5PEDIU//eRl4yevv6+KVZO3lbcuV1Wi2HYgTi8XK3ziv8O+tBv3dwex07iZgxhx4 s8gU3ETJBxy+m4BXbs3GbWniNMPrsyinmHiYB1Oi61yQplYQRcw9v68fhbufYbh0 fV12PUdRJPgMBIidpzKV9RZsffDxkLRLdkFQ9bX9J1h5iBgyEDEBrByUVwSXKfRh TGSJ6L2e0n3E5tjAm/ct2MztK0G2vfmTFcI3csgoWZwn0rjNSRzShAsybW4nGdWr yaTkmz+GI9O8UHHg9fD3pE01cMYtEQyIe1veehAXiqEF76NL/EERVFqA8M42DghV KaNV0nw5j+SSiKJgbe0qwEnRvzKD0MKKXQ2Pq6mvdK61+LIf01ZEeiyxa+Tf+zqc f9OQL+ZLB5kNHHAI5PQH =8WdU -----END PGP SIGNATURE----- --Apple-Mail=_76768088-71B0-4D51-B86B-FCA69329C602-- From nobody Tue Aug 4 04:43:53 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555D31A6FE9 for ; Tue, 4 Aug 2015 04:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham 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 45BUxAjljLwC for ; Tue, 4 Aug 2015 04:43:49 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EA91B36DE for ; Tue, 4 Aug 2015 04:43:46 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.167.91) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 11:43:25 +0000 Message-ID: <00f201d0ceaa$ef52fd60$4001a8c0@gateway.2wire.net> From: t.petch To: Sandra Murphy , sidr wg list References: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com> Date: Tue, 4 Aug 2015 12:44:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.91] X-ClientProxiedBy: HE1PR05CA0042.eurprd05.prod.outlook.com (25.162.181.52) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 2:O9kFj3O71JQPiJbjb/vmz4Km6SPHpad8hzcoFf/J2oGA98hz7ssjCj9uKKADGoM3bRpN4ATb+VSiFlmuE1xXwxhOMn1AA4xZyk5wqWBRI65mfBhnLJ/6cmzsnPWuYOAG6ih5rXQ4drTLs12tJy7JOwygehb8iRKonIb8ThQFj4Q=; 3:ZqUaF5XLiaWQ3GHmwb2YISJ20ZIaruKDdQVwinKliLuIJGZNgiFICVwcaiNnS6JUIHNK18EHVT/mAp0nu907tZqFsRKQHTx2lpnJK5X8EOPIdhpPXmKB0vXyaRC8a1cQtWPREo/YHKJlR+5KgnR4WA==; 25:RhB8Q17Llhth77hUgwqEqXiu6uKcQ8zX/QW3zaVC/EnOgI0yh3gFeLhuZD029rfjPBxSF++cQdciJ2n0mINvyanREYYh/YnThWbes1rlR1gx7t25UuiVOTI/Jb4Wma2VaMPycVzb5k61W9vAlmCiMIi5QSJjbuZE9qRFLJeBm5925fPo/ar4Obu5M7XySnN3n+GAyHwL3IX4wa5ewHOYuzOHlwZreXyaC/JhicMCYjBlqfKHC0BrAPUegLAs9aHZ; 4:21XZmkcuivIDjSsjELnIIaqSb/Nmm2aPm6Crbmtf7zlWlyOUmvm/ps1GAykTmCz2cXjbiBU7oL6zo6mlvIcIhv3ppVsherktZWnXjbIFyjjP+yOU1Lmw6/7+AuRPP0+N9IwoYbiG+WI3s0TpOJzd2XXAxBu+DSZut5CrlCRoA6cpgES1/yypsdQVf0R5Ar4nSfMIlnTRH/mZi3b5GdGr6LAYwDYEe+jCpNqYA28PB7OOg4GdNfOX3B/KdE/5f53opLD/e75ujuI51yOSM00oRO7eLDVD5jPRd7VIWxnLrdk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMXPR07MB053; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB053; X-Forefront-PRVS: 0658BAF71F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(189002)(377454003)(46102003)(84392001)(66066001)(87976001)(86362001)(230783001)(106356001)(189998001)(92566002)(40100003)(19580405001)(19580395003)(44716002)(68736005)(15975445007)(101416001)(1456003)(105586002)(47776003)(14496001)(64706001)(61296003)(5001960100002)(76176999)(81686999)(77156002)(50226001)(44736004)(77096005)(116806002)(62236002)(1556002)(62966003)(50986999)(33646002)(97736004)(5001770100001)(42186005)(5001830100001)(23746002)(122386002)(4001540100001)(81156007)(5001920100001)(5001860100001)(81816999)(50466002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AMXPR07MB053; 23:FRJhHJ/1MgdAkfs7f6zc8ydFyRnIBBxPWNIiTE?= =?Windows-1252?Q?UQFDMFPtPG18MzJ/ZggqA3TytOOvpFP3pyGS6IEpm7hgXYLSDEF3ctpY?= =?Windows-1252?Q?dxVEc9vtVVnEVssl3piyNuFsXavFmmr2/jTqhT+EyzlH21ROIFUXmrni?= =?Windows-1252?Q?fm5Wn1Gl3zPj0S9Ik0aRo4wHtByJ9/hxIVrdIur6oBU5y/RnfAo5APg9?= =?Windows-1252?Q?0jSE3Sb0YSCX8LtZ2HzcbWAnKqXjAJk/hvrNxSL2ISPJ51PrD7e+/krE?= =?Windows-1252?Q?T/R2oaA6JVtNof+xJMh5PpLpw6wdI2FlPNo7qEEATmiNM0v0tqKeIZVu?= =?Windows-1252?Q?8ZwYucTSkypbs9EGYJYVAZ9nRIaU78KUTBfvMnWMo0ZqW33cDj9O7Foy?= =?Windows-1252?Q?yGMxF+ZZHG+W/rA+XKntpUtObLR9EgfTXOKCutK7V/6tnW8DM/dSwQfU?= =?Windows-1252?Q?2vaScWz5FhCptAcApigCQIqrrFbMj8Km4+WkLoau8HuSfq3MGISs0VIP?= =?Windows-1252?Q?18I/jYFbL+q62yXYU78EnFU0LttMAVTxVX/yr/BczfFbniOan5cuqUYs?= =?Windows-1252?Q?EH+rLgPZv5akAQMOyz7o9PywW0d7BqKFcp3uXRcxFWMdTSNNMM+TH/Ww?= =?Windows-1252?Q?B+J+6uGrPR+76UKk7RkAuZTD+dBV6YKIOYq2lKigyGxAHQ/rCduhofmh?= =?Windows-1252?Q?dJexnqflAXr31SnfcgxPuT/cFkAICgXo+AA7Y/DQPM+VmG7YPdkDj75C?= =?Windows-1252?Q?1plr/nIE+Ws0sAqwfoXeyhd3vH0b6ec0WqQhb4vIRENphmCkNVZLZUK2?= =?Windows-1252?Q?CC6JcRiK6w5HR0iHiiXKM+32SGCURBaV4BYsxuhgLBqpAcQLsuQWh9BR?= =?Windows-1252?Q?zEgOFBvDK7CA+ArTvzenkiFwA5m0CJ0AsRQhdQJtkzzg6s1qpzlcB5na?= =?Windows-1252?Q?YK25GQ3mHvdHd9WyiTGXaYbRxXZuqrcPa/p7FYbofclam8Zx3eqPYwO+?= =?Windows-1252?Q?cSemQ0jZ0H79iWwCM57SVxOfy3rPn2IPUGcjt/IOOjhNLjFFYUIWpScW?= =?Windows-1252?Q?WjEddKZnyjzc+VUER5ID+zxSxxM+gmIoVRp/Nhb/7DFxFK6d3hLl85gv?= =?Windows-1252?Q?UUReDgHKDOM0C1pH/oqCXVZWhN0ovC2AJl7t6Ikc2iOpTjHrwfD1aSHX?= =?Windows-1252?Q?ucCrlkV0EyuNHkqgBUTkyF5vCjF7dz9AsjfIadDHG+Yzqjj/1btiuG81?= =?Windows-1252?Q?Lro4VYl+1gLLtuhHKIwdrlXVXd1woX3etedGVv+/IsJ8sq7eOZkvAO1b?= =?Windows-1252?Q?93x1Crjw4aAznhyVBbyejMx6Tn6VgoDSCEaJ97qAPS2k6nIoX/7p8OwI?= =?Windows-1252?Q?yWE2RxIBYLJlcGxcgFpKS6SmVd/8tDIuq3B15jlCO64D/fGqPILO9PQ8?= =?Windows-1252?Q?SpZr1ITuagzuwweQuqx4J97ZW7PRC/yMLnMLMtKjeuGijqPUuSyurmcR?= =?Windows-1252?Q?xjH74=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 5:2tl4B02zCWLseBE9DMOcM3JKQ/TGgCIofU/cQCCgpEwQ/OvOtPocxNwTI4cgTA4WNWV954MecW+X6/uja22UwkdO/nP4JIB53RA3Ok4Tpv9QLbBmJ21N+sFVwdOLBr7m3dprzyKYLlzCJ7DbKJDGAA==; 24:p2E7sApdnowvNMqxPPFsOCSmIw+QKVBGOrc6pDxoK2AVCo2jieiqQMRdgjX94KO4375vn7ktflavyQW47tHWR3k49W5itsMfrIflzcmT48Y=; 20:oncQAmWq6T99av+oIi7iuhMKXuCeJ71GC5YqUr10arQXx4tzhftlxj53aEoKgiYVaLlyxLl8Y/8Q3lK9LbzQIA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2015 11:43:25.2799 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053 Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 11:43:51 -0000 Option 3. I see a lot of base64 in e-mail and the line breaks are always there so I did not know they were taboo. It would be nice to have a sentence or two as to why they are needed. Tom Petch ----- Original Message ----- From: "Sandra Murphy" To: "sidr wg list" Cc: "Sandra Murphy" Sent: Tuesday, August 04, 2015 12:06 PM > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Aug 4 06:50:57 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657361B2E0D for ; Tue, 4 Aug 2015 06:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 eQx6exwdbVCF for ; Tue, 4 Aug 2015 06:50:55 -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 D45671B31EE for ; Tue, 4 Aug 2015 06:48:41 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id A3C867CBD for ; Tue, 4 Aug 2015 13:48:39 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 6347819EBD3A for ; Tue, 4 Aug 2015 09:48:55 -0400 (EDT) Date: Tue, 04 Aug 2015 09:48:55 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com> References: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20150804134855.6347819EBD3A@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 13:50:56 -0000 At Tue, 4 Aug 2015 07:06:22 -0400, Sandra Murphy wrote: >=20 > Speaking as document shepherd. >=20 > The IETF Last Call for draft-ietf-sidr-rfc6490-bis-04.txt ended on 23 J= uly 2015. >=20 > One issue of substance arose - permitting or forbidding line breaks > in the base64 encoding of the trust anchor, and, if permitted, at > what max line length. I know I'm going to regret this, but somebody has to say it. This is not a substantive issue. This is an example of: https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality In this case it's even sillier than usual, because we have multiple interoperable implementations in the field and there is no real problem here that needs to be solved. So the bikeshed was built years ago and we are now arguing about what color it should have been painted in some alternate universe. > Preferences for Richard?s option #2 (allow but do not mandate line > breaks) or for Richard?s option #3 (mandate line breaks)? Note that > option #3 means we have to settle on a max line length. Option #2 matches the running code. Absent some pressing need to make TALs fit on punch cards, the only benefit that option #3 brings is the opportunity to declare running code retroactively out of spec for trivial reasons. From nobody Tue Aug 4 11:32:35 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35591ACDD0; Tue, 4 Aug 2015 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=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 2hUe6lq6IDHk; Tue, 4 Aug 2015 11:32:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D780F1ACDCB; Tue, 4 Aug 2015 11:32:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804183233.23500.8213.idtracker@ietfa.amsl.com> Date: Tue, 04 Aug 2015 11:32:33 -0700 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6490-bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-rfc6490-bis-04: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 18:32:35 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-rfc6490-bis-04: 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-rfc6490-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think it would be helpful to explain in Section 1 what the purpose is for having multiple URIs in a TAL. It is implied in Section 2.2 but would help to make it explicit. Regarding this text in 2.2: "In order to operational increase resilience, it is RECOMMENDED that the domain name parts of each of these URIs resolve to distinct IP addresses that are used by a diverse set of repository publication points, and these IP addresses be included in distinct Route Origination Authorizations (ROAs) objects signed by different CAs.” I think it would be good to point out why one might construct a TAL with URIs that do resolve to the same address in the exceptional case. Alvaro pointed out one case to me offline (diversity of DNS resolution despite the address sharing), but it might help to make the exception case explicit. From nobody Tue Aug 4 12:08:41 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20F11A0015 for ; Tue, 4 Aug 2015 12:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 aFkEMMs1cOue for ; Tue, 4 Aug 2015 12:08:30 -0700 (PDT) Received: from nm8-vm5.access.bullet.mail.gq1.yahoo.com (nm8-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885A31ACEF6 for ; Tue, 4 Aug 2015 12:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1438715286; bh=l267kRAuikb4rJtiU8YkQF0C3eyEwHhTjb5JLujGEhc=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=Ced9H2JDAm58NfH6OaCqwEJQlLYB9Ghblrca6+tz8jvRExe1+un16apL5xHiPAx+A3eflqwVIT3QFLsafWRbye+/ltWqf64oKwybdrfllnITvJgLOVTRyTpMu1PmIWcjF92GRApHLk+2DkSaAbXK9PaCxJhz0lXUROGV/Zc4kJoRb77k2c7XrAKxdKDHL4UAplW5SlzGeudp5LT2R6WoZDNPrKNhrRg5O4wxCWk7GfFzHuLGozBzTBAhdP54uQ4ZH0CSCQ0BnBCG70LkJwSGGVhDx1WYAEDYe0mm87YKyWYW7Y/DT+vPBlj236Lv+6t/dxuBFkq+dnRBpSUeOF5hog== Received: from [216.39.60.168] by nm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Aug 2015 19:08:06 -0000 Received: from [98.138.226.244] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Aug 2015 19:08:06 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 04 Aug 2015 19:08:06 -0000 X-Yahoo-Newman-Id: 125579.27681.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .XTUfgAVM1kVHS7bjEMJlqHGdaQp3oEJVfjet.i3sMkeaoP j9EG7.z6cPrVMjwchHTVZrWd220uR4A.802BtOyWXURj4c6R_Q1T0XVsHfTN YozuDsLT8cTjsFHlJwzJpqzXuGSI6.zU9X945HNb6D_TBiVlvbxrGotFbHCk OQSXtXvwvIKzOrylIUWGgaQuPPk2.qydh8SNKiYP7TlWQ8KorlUtB9WGmsYD vIt0VLhEXt55GkjU1GWRquINSHcy33jTfg3mVL2Q.G6igFn01cn93OiFpbPA .Dz4J84HKVj9M0mVj0DdzRonrVWIUNkoOz_gz5a92pQAyxMJjGHLfyr8ZJkJ w6VjemNG4Anm2EziQ_Y78Au2nDHw2aWWtGrR1DHSdrsP6vgaQFpn0y4dGQ9z YROT8SqFtpX6UCcZtOFlSUMakQbNjeCfZgYpbs4DoTMqWwseO9AQ6Nv8_d4D C8.5_fsE62rcCEZKBQ78PT9Us7NqFaxcQ6prBX8lpwJz6l71thyYKZE.QxH3 wr7xPtvRKiIJpvGB_8Gnav2TjgxE.hDtxkWihaA-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E99581C6052 for ; Tue, 4 Aug 2015 15:08:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 04 Aug 2015 15:08:04 -0400 From: David Mandelberg To: In-Reply-To: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com> References: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com> Message-ID: <0b0b017606fba4841f014a2686ccb945@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 19:08:33 -0000 On 2015-08-04 07:06, Sandra Murphy wrote: > Preferences for Richard=E2=80=99s option #2 (allow but do not mandate l= ine > breaks) or for Richard=E2=80=99s option #3 (mandate line breaks)? Note= that > option #3 means we have to settle on a max line length. I have a slight preference for #2 since it probably requires the least=20 total work. If somebody down the road really can't handle lines longer=20 than X columns, locally re-wrapping lines in a TAL is really easy to do=20 in many text editors or scripting languages. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Aug 4 21:40:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F201B1ACE2E for ; Tue, 4 Aug 2015 21:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vitBkB3TS9Z5 for ; Tue, 4 Aug 2015 21:40:03 -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 838FF1ACDEE for ; Tue, 4 Aug 2015 21:40:03 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:41377) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZMqUj-00058t-Ob; Wed, 05 Aug 2015 00:40:01 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 5E363401A8 Message-ID: <55C19391.6000302@bbn.com> Date: Wed, 05 Aug 2015 00:39:45 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Rob Austein , sidr@ietf.org References: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com> <20150804134855.6347819EBD3A@minas-ithil.hactrn.net> In-Reply-To: <20150804134855.6347819EBD3A@minas-ithil.hactrn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 04:40:05 -0000 On 2015-08-04 09:48, Rob Austein wrote: > At Tue, 4 Aug 2015 07:06:22 -0400, Sandra Murphy wrote: >> Preferences for Richard?s option #2 (allow but do not mandate line >> breaks) or for Richard?s option #3 (mandate line breaks)? Note that >> option #3 means we have to settle on a max line length. >=20 > Option #2 matches the running code. >=20 > Absent some pressing need to make TALs fit on punch cards, the only > benefit that option #3 brings is the opportunity to declare running > code retroactively out of spec for trivial reasons. I'm confused by your "out of spec" comment. In what way would option #3 render existing code out of spec where option #2 wouldn't? The advantage to option #3 is compatibility with OpenSSL's lame base64 implementation. My stated preference for option #3 should not be taken as a strong preference. I am OK with option #2: it's not much harder for people to implement (working around OpenSSL's problems is annoying but not difficult), it puts a tiny bit of pressure on OpenSSL to improve their implementation, and it avoids the need to decide on a specific maximum line length. -Richard From nobody Wed Aug 5 06:31:48 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733F51A87E7; Wed, 5 Aug 2015 06:31:45 -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] autolearn=ham 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 8c16meivwiAc; Wed, 5 Aug 2015 06:31:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEDB1A87A8; Wed, 5 Aug 2015 06:31:44 -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.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805133144.20399.96252.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 06:31:44 -0700 Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-rfc6490-bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rfc6490-bis-04: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 13:31:45 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-rfc6490-bis-04: 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-rfc6490-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - (In response to Ben's comment:) Assuming this change only represents a change to the means to get more anchor information, after you have the public key, and that any additional into is protected with the key I don't think there's any real security change here - this is basically like having an anycast address for the host in the current URI (from the security POV). If that's wrong please do correct me. - tbh, I don't find the new text describing the syntax to be very clear. It says: "...where the URI section is comprised of one of more of the ordered sequence of: 1.1) an rsync URI [RFC5781], 1.2) a or line break." Exactly what is supposed to separate the URIs? - the example should show >1 URL really From nobody Wed Aug 5 09:40:36 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1152D1A21C7; Wed, 5 Aug 2015 09:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4ysc0kHtbGtW; Wed, 5 Aug 2015 09:40:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DFA971B3192; Wed, 5 Aug 2015 09:40:22 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t75Ge5S4061611 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2015 11:40:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Stephen Farrell" Date: Wed, 05 Aug 2015 11:40:05 -0500 Message-ID: In-Reply-To: <20150805133144.20399.96252.idtracker@ietfa.amsl.com> References: <20150805133144.20399.96252.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: sandy@tislabs.com, sidr-chairs@ietf.org, draft-ietf-sidr-rfc6490-bis@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rfc6490-bis-04: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:40:26 -0000 On 5 Aug 2015, at 8:31, Stephen Farrell wrote: > - (In response to Ben's comment:) Assuming this change > only represents a change to the means to get more > anchor information, after you have the public key, and > that any additional into is protected with the key I > don't think there's any real security change here - this > is basically like having an anycast address for the host > in the current URI (from the security POV). If that's > wrong please do correct me. I believe you are right, and that addresses my concern. Thanks! Ben. From nobody Thu Aug 6 14:52:03 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596C71A8F41 for ; Thu, 6 Aug 2015 14:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 BVDuOA5D1Fmj for ; Thu, 6 Aug 2015 14:51:59 -0700 (PDT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.146.82]) (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 5CDE31A8BC0 for ; Thu, 6 Aug 2015 14:51:59 -0700 (PDT) Received: by gateway33.websitewelcome.com (Postfix, from userid 500) id C7FA5C7080529; Thu, 6 Aug 2015 16:51:58 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway33.websitewelcome.com (Postfix) with ESMTP id B4238C70804D7 for ; Thu, 6 Aug 2015 16:51:58 -0500 (CDT) Received: from [96.231.221.219] (port=61136 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZNT4w-000KWp-3z for sidr@ietf.org; Thu, 06 Aug 2015 16:51:58 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <2C6935CA-971B-45E0-BF42-AAB9FAAD2335@apnic.net> Date: Thu, 6 Aug 2015 17:51:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <45ADF162-AB39-4342-9A60-C3A1FF395FC6@ieca.com> References: <20150724133255.23566.85626.idtracker@ietfa.amsl.com> <2C6935CA-971B-45E0-BF42-AAB9FAAD2335@apnic.net> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.221.219 X-Exim-ID: 1ZNT4w-000KWp-3z X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:61136 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 21:52:01 -0000 This one looks good - let=92s ship it! spt On Jul 25, 2015, at 04:47, Geoff Huston wrote: > With many thanks to Richard Hansen for his editing of this draft, I = believe that > this draft addresses both the underlying tech issue that was unable to = be addressed > in an erratum, and also addressed the other outstanding errata = reported for RFC 6485,=20 > as well as correcting minor nits that escaped the eagle eyes of = various reviewers of > the RFC and previous versions of this draft, and hopefully I=92ve = avoided adding > more nits in my final markup! >=20 > Chairs (well, specifically Sandy, as she has been working with me on = getting this > document ready), I=92m not sure of the current WG status of this = document, wrt last > calls, etc, but I believe its about as cooked as it is ever going to = be! >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >=20 >> On 24 Jul 2015, at 3:32 pm, internet-drafts@ietf.org wrote: >>=20 >>=20 >> 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 Working = Group of the IETF. >>=20 >> Title : The Profile for Algorithms and Key Sizes for = use in the Resource Public Key Infrastructure >> Authors : Geoff Huston >> George Michaelson >> Filename : draft-ietf-sidr-rfc6485bis-03.txt >> Pages : 9 >> Date : 2015-07-24 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-03 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6485bis-03 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 Thu Aug 6 16:52:19 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1A81B3D5E for ; Thu, 6 Aug 2015 16:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 hNvlkQaBoNLE for ; Thu, 6 Aug 2015 16:52:15 -0700 (PDT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.182]) (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 049801ACEAE for ; Thu, 6 Aug 2015 16:52:15 -0700 (PDT) Received: by gateway32.websitewelcome.com (Postfix, from userid 500) id 5D5DCC699555B; Thu, 6 Aug 2015 18:52:14 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 497C9C699552D for ; Thu, 6 Aug 2015 18:52:14 -0500 (CDT) Received: from [96.231.221.219] (port=61497 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZNUxJ-000VWB-FQ; Thu, 06 Aug 2015 18:52:13 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <555F436F.3080003@bbn.com> Date: Thu, 6 Aug 2015 19:52:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> References: <555F436F.3080003@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.221.219 X-Exim-ID: 1ZNUxJ-000VWB-FQ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:61497 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: sidr wg list Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 23:52:17 -0000 On May 22, 2015, at 10:55, Richard Hansen wrote: > Hi all, >=20 > A while back Sean Turner raised the idea of switching to SHA-256 for = the > Subject Key Identifier while discussing rfc6487bis (see > ). I see a couple of > reasons to do this: >=20 > * If/when additional weaknesses are found in SHA-1, 3rd party > cryptographic libraries that implement SHA-1 may become hard to > find. >=20 > * If/when a serious weakness is found in SHA-1, someone might be > able to exploit the weakness to attack some aspect of RPKI/BGPsec. >=20 > Thinking about the latter, I believe there is a = not-entirely-implausible > attack that might justify a change: >=20 > 1. An attacker uses a weakness in SHA-1 to generate a large number of > BGPsec router certificates for an AS, where each certificate has a > different key but the same SKI. >=20 > 2. The attacker uses one of those certificates to generate a > signature segment in the BGPsec_Path attribute, and sends the > BGPsec Update message to a peer. >=20 > 3. The peer starts the process of validating the signature segment > generated by the attacker. Due to the numerous keys with the same > SKI, the peer is forced to test each of the attacker's keys one by > one until a match is found. This could take a considerable amount > of time. >=20 > 4. While it is validating the signature, the peer processes all > Update messages as if they were unsigned because there is not > enough CPU available at the moment. The attacker has succeeded in > (temporarily) disabling BGPsec. >=20 > One way to block the above attack is to use a stronger hash function > (e.g., SHA-256) for the SKI. Unfortunately, because the SKI extension > doesn't have an algorithm identifier field, there's no way to switch > without a flag day. >=20 > We could make a proactive change now while deployment is low, but it > would still be unpleasant. >=20 > An alternative idea suggested by Matt Lepinski is to prohibit router > certificate SKI collisions within an AS if the keys differ. In other > words, if there are two valid BGPsec router certs in the same AS with > different keys but the same SKI, then RPs MUST mark them both as > invalid. Thanks to the RFC3779 checks, it would not be possible for > someone in a different AS to invalidate your certs even if a weakness = in > SHA-1 was discovered. >=20 > So I propose we add something like the following to the end of Section = 3 > in draft-ietf-sidr-bgpsec-pki-profiles: >=20 > o To prevent denial-of-service attacks against RPs, Subject Key > Identifier collisions within an AS are not permitted. Any > BGPsec Router Certificate that: > * references the same AS number in the Autonomous System > Identifier Delegation extension, > * has a different key, and > * has the same value in the Subject Key Identifier extension > as another otherwise valid certificate MUST NOT be considered > valid. >=20 > We may also want to add something to rfc6487bis to invalidate a > certificate if its SKI matches an ancestor (and the key differs), = though > I can't think of a way to take advantage of such a collision at the = moment. >=20 > Thoughts? >=20 > Thanks, > Richard I=92m all for switching to using a better hash algorithm to avoid = collisions, but why can=92t we just do it anytime we want? The SKI/AKI = fields are only ever generated by a CA so the RPs don=92t need to know = the algorithm used. What I am/was suggesting we do is make the following change in Section = 4.8.2/3 to RFC 6487: OLD: The Key Identifier used for resource certificates is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the Subject Public Key, as described in Section 4.2.1.1/2 of [RFC5280]. NEW: The Key Identifier used for resource certificates is the 160-bit SHA-256 hash of the value of the DER-encoded ASN.1 bit string of the Subject Public Key, as described in Section 2 of [RFC7093]. As far as you tweaks to the bgpsec-pki-profile draft, if we can do these = checks without calculating the AKI/SKI values I=92m all for this [0], = but I guess I=92m curious why collisions outside the AS would be = allowed? Shouldn=92t it be: To prevent denial-of-service attacks against RPs, Subject Key Identifier collisions are not permitted. Any BGPsec Router Certificate that: * references the same AS number in the Autonomous System Identifier Delegation extension, * has a different key, and * has the same value in the Subject Key Identifier extension as another otherwise valid certificate MUST NOT be considered valid. spt [0] Full disclosure: I co-authored RFC 7093 "Additional Methods for = Generating Key Identifiers Values=94.= From nobody Thu Aug 6 17:03:30 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AC31B3DA0; Thu, 6 Aug 2015 17:03:27 -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] autolearn=ham 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 CrL_wnG7xgpz; Thu, 6 Aug 2015 17:03:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089721B3DD1; Thu, 6 Aug 2015 17:02:41 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150807000241.24892.74563.idtracker@ietfa.amsl.com> Date: Thu, 06 Aug 2015 17:02:41 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:03:27 -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 Working Group of the IETF. Title : BGPsec Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-11.txt Pages : 7 Date : 2015-08-06 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-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 Thu Aug 6 17:09:10 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17B61A1ADA for ; Thu, 6 Aug 2015 17:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 EfkBSVrEfu4E for ; Thu, 6 Aug 2015 17:09:07 -0700 (PDT) Received: from gateway22.websitewelcome.com (gateway22.websitewelcome.com [192.185.46.234]) (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 83E681ACEA6 for ; Thu, 6 Aug 2015 17:09:07 -0700 (PDT) Received: by gateway22.websitewelcome.com (Postfix, from userid 500) id 99A81C6D4462F; Thu, 6 Aug 2015 19:09:06 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway22.websitewelcome.com (Postfix) with ESMTP id 86732C6D44615 for ; Thu, 6 Aug 2015 19:09:06 -0500 (CDT) Received: from [96.231.221.219] (port=61589 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZNVDc-000Aj5-Vw for sidr@ietf.org; Thu, 06 Aug 2015 19:09:05 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20150807000241.24892.74563.idtracker@ietfa.amsl.com> Date: Thu, 6 Aug 2015 20:09:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <991518EB-6209-42B4-B001-0BF086C027B4@ieca.com> References: <20150807000241.24892.74563.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.221.219 X-Exim-ID: 1ZNVDc-000Aj5-Vw X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:61589 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:09:09 -0000 I took the liberty of updating the reference to 6485bis. spt On Aug 06, 2015, at 20:02, internet-drafts@ietf.org wrote: >=20 > 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 Working = Group of the IETF. >=20 > Title : BGPsec Algorithms, Key Formats, & Signature = Formats > Author : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-11.txt > Pages : 7 > Date : 2015-08-06 >=20 > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPsec (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-11 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Aug 6 17:10:18 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CCA1B31C9; Thu, 6 Aug 2015 17:10:15 -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] autolearn=ham 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 9SUNAa_Dbrod; Thu, 6 Aug 2015 17:10:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEA11B3358; Thu, 6 Aug 2015 17:10:12 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150807001012.2542.69550.idtracker@ietfa.amsl.com> Date: Thu, 06 Aug 2015 17:10:12 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:10:15 -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 Working Group of the IETF. Title : A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-11.txt Pages : 12 Date : 2015-08-06 Abstract: This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is a critical component for the proper operation of the Internet as a whole. The BGPsec protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPsec is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS) or ASes. The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS(es). This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-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 Thu Aug 6 17:33:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0F51AC3DF for ; Thu, 6 Aug 2015 17:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 MEDPvyqevf-1 for ; Thu, 6 Aug 2015 17:33:15 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (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 69E1F1AC3D8 for ; Thu, 6 Aug 2015 17:33:15 -0700 (PDT) Received: by qgeg42 with SMTP id g42so28493453qge.1 for ; Thu, 06 Aug 2015 17:33:14 -0700 (PDT) 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:to:cc:content-type; bh=haJvwGZEkDIkl3+1mxLaALhTSpnrg32/unmkGlM+s4Y=; b=nFicplCoJGolWUnl4q6mYsQ6Z1SEv6ynQ3N8UaAuD0GW8andUhv3+T/x6SuPC1GlUZ HX9qsFlIyRNMXto+APHH9ub5hpIDQtPXTQGhz30IUyrNdvnUraGcksgpRikIkUv1uRuo qhPR5E7cHArLPmKgaHL4fGyYGYePr2G6NEEiETkkIHImLf0sGFhgXViXo/eSU3DgqquM FE6uSRqFFaeBNM7SHj3Bo5ITR5LW+OLfz55A7dnkGJoEIXvIpNGMVCKhrA2upJ7wTcn1 Ak2fRwgPizw+HzvHcVfa0QcIudJuo4pJnFJYpW6ASbmCit7CDQO7tBu50RPMExOA1N5V nUMQ== X-Gm-Message-State: ALoCoQkoZO9BG8FftfAUFI66FYsbe9f7syGjcy9hMpTdgn+Oi4TpVagnkFk/Hw2K5WPnerJtUFZy MIME-Version: 1.0 X-Received: by 10.140.107.180 with SMTP id h49mr8158167qgf.1.1438907594438; Thu, 06 Aug 2015 17:33:14 -0700 (PDT) Received: by 10.96.2.67 with HTTP; Thu, 6 Aug 2015 17:33:14 -0700 (PDT) X-Originating-IP: [167.63.12.4] In-Reply-To: <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> Date: Thu, 6 Aug 2015 21:33:14 -0300 Message-ID: From: George Michaelson To: Sean Turner Content-Type: multipart/alternative; boundary=001a113a804a081364051cadc8f6 Archived-At: Cc: sidr wg list , Richard Hansen Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:33:19 -0000 --001a113a804a081364051cadc8f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you give me some indication at what level of operation a SHA1 over the public key risks colliding? 0.001? 0.00001? I don't want to impede progress if SHA256 is sensible, but I have a feeling this is a risk almost at the noise floor. Since its per-CA, the CA is presumed to have to hand a complete set of all the active keys its signed over, and presumably could say: "damn. collide" -not that it has much choice about what to do, to get over this. Its possible we're just hunting more 0.000s down the road. There are <1m discrete prefixes in the current routing system, and less than 256,000 actors in this specific (non-BGP router key, not path key) space of allocations and assignments (we're only just walking into 4 byte ASN territory so the real number of actors is very possibly far smaller, but its more than the total count of ASN since many prefix holders in Asia don't have ASN and sign ROA over somebody else's ASN, but clearly, its bounded by the prefix count. So I feel ok saying it lies between 64k and 1m= ) There is a minimum break-out of 5-way near the top, lets assume they equi position (they don't) and say between 16k and 256k per top CA, thats me asking you if a SHA1 hash over the keys, in 256,000 sign-overs, is likely to collide. Anyone else has far fewer. Most CA has less than 10000 and very probably less than 1000 things to sign over. Even the APNIC flat world has less than 256k things to sign over. I know; I could spin up the dice (again) I did this for about 60,000 when I first tested things before we had a design. I did not even collide in the crude OpenSSL hash name model, let alone the SKI hash. Pragmatism is not good. I'm fine with a respin to put this to SHA256 but might we not just want to say "...plus a -1 -2 -3 generational qualifier should a collision occur" and avoid any risk? -G On Thu, Aug 6, 2015 at 8:52 PM, Sean Turner wrote: > > On May 22, 2015, at 10:55, Richard Hansen wrote: > > > Hi all, > > > > A while back Sean Turner raised the idea of switching to SHA-256 for th= e > > Subject Key Identifier while discussing rfc6487bis (see > > ). I see a couple of > > reasons to do this: > > > > * If/when additional weaknesses are found in SHA-1, 3rd party > > cryptographic libraries that implement SHA-1 may become hard to > > find. > > > > * If/when a serious weakness is found in SHA-1, someone might be > > able to exploit the weakness to attack some aspect of RPKI/BGPsec. > > > > Thinking about the latter, I believe there is a not-entirely-implausibl= e > > attack that might justify a change: > > > > 1. An attacker uses a weakness in SHA-1 to generate a large number of > > BGPsec router certificates for an AS, where each certificate has a > > different key but the same SKI. > > > > 2. The attacker uses one of those certificates to generate a > > signature segment in the BGPsec_Path attribute, and sends the > > BGPsec Update message to a peer. > > > > 3. The peer starts the process of validating the signature segment > > generated by the attacker. Due to the numerous keys with the same > > SKI, the peer is forced to test each of the attacker's keys one by > > one until a match is found. This could take a considerable amount > > of time. > > > > 4. While it is validating the signature, the peer processes all > > Update messages as if they were unsigned because there is not > > enough CPU available at the moment. The attacker has succeeded in > > (temporarily) disabling BGPsec. > > > > One way to block the above attack is to use a stronger hash function > > (e.g., SHA-256) for the SKI. Unfortunately, because the SKI extension > > doesn't have an algorithm identifier field, there's no way to switch > > without a flag day. > > > > We could make a proactive change now while deployment is low, but it > > would still be unpleasant. > > > > An alternative idea suggested by Matt Lepinski is to prohibit router > > certificate SKI collisions within an AS if the keys differ. In other > > words, if there are two valid BGPsec router certs in the same AS with > > different keys but the same SKI, then RPs MUST mark them both as > > invalid. Thanks to the RFC3779 checks, it would not be possible for > > someone in a different AS to invalidate your certs even if a weakness i= n > > SHA-1 was discovered. > > > > So I propose we add something like the following to the end of Section = 3 > > in draft-ietf-sidr-bgpsec-pki-profiles: > > > > o To prevent denial-of-service attacks against RPs, Subject Key > > Identifier collisions within an AS are not permitted. Any > > BGPsec Router Certificate that: > > * references the same AS number in the Autonomous System > > Identifier Delegation extension, > > * has a different key, and > > * has the same value in the Subject Key Identifier extension > > as another otherwise valid certificate MUST NOT be considered > > valid. > > > > We may also want to add something to rfc6487bis to invalidate a > > certificate if its SKI matches an ancestor (and the key differs), thoug= h > > I can't think of a way to take advantage of such a collision at the > moment. > > > > Thoughts? > > > > Thanks, > > Richard > > I=E2=80=99m all for switching to using a better hash algorithm to avoid > collisions, but why can=E2=80=99t we just do it anytime we want? The SKI= /AKI > fields are only ever generated by a CA so the RPs don=E2=80=99t need to k= now the > algorithm used. > > What I am/was suggesting we do is make the following change in Section > 4.8.2/3 to RFC 6487: > > OLD: > > The Key Identifier used for resource certificates is the 160-bit > SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the > Subject Public Key, as described in Section 4.2.1.1/2 of [RFC5280]. > > NEW: > > The Key Identifier used for resource certificates is the 160-bit > SHA-256 hash of the value of the DER-encoded ASN.1 bit string of the > Subject Public Key, as described in Section 2 of [RFC7093]. > > As far as you tweaks to the bgpsec-pki-profile draft, if we can do these > checks without calculating the AKI/SKI values I=E2=80=99m all for this [0= ], but I > guess I=E2=80=99m curious why collisions outside the AS would be allowed?= Shouldn=E2=80=99t > it be: > > To prevent denial-of-service attacks against RPs, Subject Key > Identifier collisions are not permitted. Any BGPsec Router > Certificate that: > * references the same AS number in the Autonomous System > Identifier Delegation extension, > * has a different key, and > * has the same value in the Subject Key Identifier extension > as another otherwise valid certificate MUST NOT be > considered valid. > > spt > > [0] Full disclosure: I co-authored RFC 7093 "Additional Methods for > Generating Key Identifiers Values=E2=80=9D. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a113a804a081364051cadc8f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you give me some indication at what level of operation= a SHA1 over the public key risks colliding? 0.001? 0.00001?

=
I don't want to impede progress if SHA256 is sensible, but I have = a feeling this is a risk almost at the noise floor. Since its per-CA, the C= A is presumed to have to hand a complete set of all the active keys its sig= ned over, and presumably could say: "damn. collide" -not that it = has much choice about what to do, to get over this.

Its possible we're just hunting more 0.000s down the road.
=
There are <1m discrete prefixes in the current routing sy= stem, and less than 256,000 actors in this specific (non-BGP router key, no= t path key) space of allocations and assignments (we're only just walki= ng into 4 byte ASN territory so the real number of actors is very possibly = far smaller, but its more than the total count of ASN since many prefix hol= ders in Asia don't have ASN and sign ROA over somebody else's ASN, = but clearly, its bounded by the prefix count. So I feel ok saying it lies b= etween 64k and 1m)

There is a minimum break-out of= 5-way near the top, lets assume they equi position (they don't) and sa= y between 16k and 256k per top CA, thats me asking you if a SHA1 hash over = the keys, in 256,000 sign-overs, is likely to collide. Anyone else has far = fewer. Most CA has less than 10000 and very probably less than 1000 things = to sign over. Even the APNIC flat world has less than 256k things to sign o= ver.

I know; I could spin up the dice (again)

I did this for about 60,000 when I first tested things= before we had a design. I did not even collide in the crude OpenSSL hash n= ame model, let alone the SKI hash.

Pragmatism is n= ot good. I'm fine with a respin to put this to SHA256 but might we not = just want to say "...plus a -1 -2 -3 generational qualifier should a c= ollision occur" and avoid any risk?

-G
<= /div>

On Thu, Aug = 6, 2015 at 8:52 PM, Sean Turner <turners@ieca.com> wrote:
=

On May 22, 2015, at 10:55, Richard Hansen <rhansen@bbn.com> wrote:

> Hi all,
>
> A while back Sean Turner raised the idea of switching to SHA-256 for t= he
> Subject Key Identifier while discussing rfc6487bis (see
> <http://article.gmane.org/gmane.ietf.sidr/6878<= /a>>).=C2=A0 I see a couple of
> reasons to do this:
>
>=C2=A0 *=C2=A0 If/when additional weaknesses are found in SHA-1, 3rd pa= rty
>=C2=A0 =C2=A0 =C2=A0cryptographic libraries that implement SHA-1 may be= come hard to
>=C2=A0 =C2=A0 =C2=A0find.
>
>=C2=A0 *=C2=A0 If/when a serious weakness is found in SHA-1, someone mi= ght be
>=C2=A0 =C2=A0 =C2=A0able to exploit the weakness to attack some aspect = of RPKI/BGPsec.
>
> Thinking about the latter, I believe there is a not-entirely-implausib= le
> attack that might justify a change:
>
>=C2=A0 1. An attacker uses a weakness in SHA-1 to generate a large numb= er of
>=C2=A0 =C2=A0 =C2=A0BGPsec router certificates for an AS, where each ce= rtificate has a
>=C2=A0 =C2=A0 =C2=A0different key but the same SKI.
>
>=C2=A0 2. The attacker uses one of those certificates to generate a
>=C2=A0 =C2=A0 =C2=A0signature segment in the BGPsec_Path attribute, and= sends the
>=C2=A0 =C2=A0 =C2=A0BGPsec Update message to a peer.
>
>=C2=A0 3. The peer starts the process of validating the signature segme= nt
>=C2=A0 =C2=A0 =C2=A0generated by the attacker.=C2=A0 Due to the numerou= s keys with the same
>=C2=A0 =C2=A0 =C2=A0SKI, the peer is forced to test each of the attacke= r's keys one by
>=C2=A0 =C2=A0 =C2=A0one until a match is found.=C2=A0 This could take a= considerable amount
>=C2=A0 =C2=A0 =C2=A0of time.
>
>=C2=A0 4. While it is validating the signature, the peer processes all<= br> >=C2=A0 =C2=A0 =C2=A0Update messages as if they were unsigned because th= ere is not
>=C2=A0 =C2=A0 =C2=A0enough CPU available at the moment.=C2=A0 The attac= ker has succeeded in
>=C2=A0 =C2=A0 =C2=A0(temporarily) disabling BGPsec.
>
> One way to block the above attack is to use a stronger hash function > (e.g., SHA-256) for the SKI.=C2=A0 Unfortunately, because the SKI exte= nsion
> doesn't have an algorithm identifier field, there's no way to = switch
> without a flag day.
>
> We could make a proactive change now while deployment is low, but it > would still be unpleasant.
>
> An alternative idea suggested by Matt Lepinski is to prohibit router > certificate SKI collisions within an AS if the keys differ.=C2=A0 In o= ther
> words, if there are two valid BGPsec router certs in the same AS with<= br> > different keys but the same SKI, then RPs MUST mark them both as
> invalid.=C2=A0 Thanks to the RFC3779 checks, it would not be possible = for
> someone in a different AS to invalidate your certs even if a weakness = in
> SHA-1 was discovered.
>
> So I propose we add something like the following to the end of Section= 3
> in draft-ietf-sidr-bgpsec-pki-profiles:
>
>=C2=A0 =C2=A0 o To prevent denial-of-service attacks against RPs, Subje= ct Key
>=C2=A0 =C2=A0 =C2=A0 Identifier collisions within an AS are not permitt= ed.=C2=A0 Any
>=C2=A0 =C2=A0 =C2=A0 BGPsec Router Certificate that:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 references the same AS number in th= e Autonomous System
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identifier Delegation extensio= n,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 has a different key, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 has the same value in the Subject K= ey Identifier extension
>=C2=A0 =C2=A0 =C2=A0 as another otherwise valid certificate MUST NOT be= considered
>=C2=A0 =C2=A0 =C2=A0 valid.
>
> We may also want to add something to rfc6487bis to invalidate a
> certificate if its SKI matches an ancestor (and the key differs), thou= gh
> I can't think of a way to take advantage of such a collision at th= e moment.
>
> Thoughts?
>
> Thanks,
> Richard

I=E2=80=99m all for switching to using a better hash algorithm = to avoid collisions, but why can=E2=80=99t we just do it anytime we want?= =C2=A0 The SKI/AKI fields are only ever generated by a CA so the RPs don=E2= =80=99t need to know the algorithm used.

What I am/was suggesting we do is make the following change in Section 4.8.= 2/3 to RFC 6487:

OLD:

=C2=A0 The Key Identifier used for resource certificates is the 160-bit
=C2=A0 SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the =C2=A0 Subject Public Key, as described in Section 4.2.1.1/2 of [RFC5280].

NEW:

=C2=A0 The Key Identifier used for resource certificates is the 160-bit
=C2=A0 SHA-256 hash of the value of the DER-encoded ASN.1 bit string of the=
=C2=A0 Subject Public Key, as described in Section 2 of [RFC7093].

As far as you tweaks to the bgpsec-pki-profile draft, if we can do these ch= ecks without calculating the AKI/SKI values I=E2=80=99m all for this [0], b= ut I guess I=E2=80=99m curious why collisions outside the AS would be allow= ed? Shouldn=E2=80=99t it be:

=C2=A0 To prevent denial-of-service attacks against RPs, Subject Key
=C2=A0 Identifier collisions are not permitted.=C2=A0 Any BGPsec Rou= ter
=C2=A0 Certificate that:
=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 references the same AS number in the Aut= onomous System
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identifier Delegation extension,
=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 has a different key, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 has the same value in the Subject Key Id= entifier extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as another otherwise valid certificate M= UST NOT be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considered valid.

spt

[0] Full disclosure: I co-authored RFC 7093 "Additional Methods for Ge= nerating Key Identifiers Values=E2=80=9D.
___________________________________= ____________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

--001a113a804a081364051cadc8f6-- From nobody Thu Aug 6 17:56:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193BB1ACED0 for ; Thu, 6 Aug 2015 17:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 qIlruB7pn5C2 for ; Thu, 6 Aug 2015 17:56:36 -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 CB64E1ACED7 for ; Thu, 6 Aug 2015 17:56:35 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:41762) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZNVxa-000P9n-68; Thu, 06 Aug 2015 20:56:34 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id BD6363FEF7 Message-ID: <55C40241.3080407@bbn.com> Date: Thu, 06 Aug 2015 20:56:33 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Sean Turner References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> In-Reply-To: <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr wg list Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:56:43 -0000 On 2015-08-06 19:52, Sean Turner wrote: >=20 > On May 22, 2015, at 10:55, Richard Hansen wrote: >=20 >> Hi all, >> >> A while back Sean Turner raised the idea of switching to SHA-256 for t= he >> Subject Key Identifier while discussing rfc6487bis (see >> ). I see a couple of >> reasons to do this: >> >> * If/when additional weaknesses are found in SHA-1, 3rd party >> cryptographic libraries that implement SHA-1 may become hard to >> find. >> >> * If/when a serious weakness is found in SHA-1, someone might be >> able to exploit the weakness to attack some aspect of RPKI/BGPsec. >> >> Thinking about the latter, I believe there is a not-entirely-implausib= le >> attack that might justify a change: >> >> 1. An attacker uses a weakness in SHA-1 to generate a large number of >> BGPsec router certificates for an AS, where each certificate has a >> different key but the same SKI. >> >> 2. The attacker uses one of those certificates to generate a >> signature segment in the BGPsec_Path attribute, and sends the >> BGPsec Update message to a peer. >> >> 3. The peer starts the process of validating the signature segment >> generated by the attacker. Due to the numerous keys with the same >> SKI, the peer is forced to test each of the attacker's keys one by >> one until a match is found. This could take a considerable amount >> of time. >> >> 4. While it is validating the signature, the peer processes all >> Update messages as if they were unsigned because there is not >> enough CPU available at the moment. The attacker has succeeded in >> (temporarily) disabling BGPsec. >> >> One way to block the above attack is to use a stronger hash function >> (e.g., SHA-256) for the SKI. Unfortunately, because the SKI extension >> doesn't have an algorithm identifier field, there's no way to switch >> without a flag day. >> >> We could make a proactive change now while deployment is low, but it >> would still be unpleasant. >> >> An alternative idea suggested by Matt Lepinski is to prohibit router >> certificate SKI collisions within an AS if the keys differ. In other >> words, if there are two valid BGPsec router certs in the same AS with >> different keys but the same SKI, then RPs MUST mark them both as >> invalid. Thanks to the RFC3779 checks, it would not be possible for >> someone in a different AS to invalidate your certs even if a weakness = in >> SHA-1 was discovered. >> >> So I propose we add something like the following to the end of Section= 3 >> in draft-ietf-sidr-bgpsec-pki-profiles: >> >> o To prevent denial-of-service attacks against RPs, Subject Key >> Identifier collisions within an AS are not permitted. Any >> BGPsec Router Certificate that: >> * references the same AS number in the Autonomous System >> Identifier Delegation extension, >> * has a different key, and >> * has the same value in the Subject Key Identifier extension >> as another otherwise valid certificate MUST NOT be considered >> valid. >> >> We may also want to add something to rfc6487bis to invalidate a >> certificate if its SKI matches an ancestor (and the key differs), thou= gh >> I can't think of a way to take advantage of such a collision at the mo= ment. >> >> Thoughts? >> >> Thanks, >> Richard >=20 > I=92m all for switching to using a better hash algorithm to avoid > collisions, but why can=92t we just do it anytime we want? The SKI/AKI > fields are only ever generated by a CA so the RPs don=92t need to know > the algorithm used. The requirement to use a particular algorithm means that some RPs (such as RPSTIR) will enforce it. We could relax the requirement and allow CAs to calculate the SKI however they want, but then collisions (accidental or intentional) become a much bigger concern. >=20 > What I am/was suggesting we do is make the following change in > Section 4.8.2/3 to RFC 6487: >=20 > OLD: >=20 > The Key Identifier used for resource certificates is the 160-bit > SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the > Subject Public Key, as described in Section 4.2.1.1/2 of [RFC5280]. >=20 > NEW: >=20 > The Key Identifier used for resource certificates is the 160-bit > SHA-256 hash of the value of the DER-encoded ASN.1 bit string of the > Subject Public Key, as described in Section 2 of [RFC7093]. SHA-256 output is 256 bits, so did you mean "the first 160 bits of the SHA-256 hash"? If we want to change the size of the SKI/AKI from 160 bits to something else then we will also have to change the rpki-rtr and BGPsec protocol specifications (at least). If we switch to SHA-256 then we still have the problem of what to do if a weakness is ever found in SHA-256. >=20 > As far as you tweaks to the bgpsec-pki-profile draft, if we can do > these checks without calculating the AKI/SKI values I=92m all for this RPs would not have to calculate/validate the SKI value; they would only need to check for collisions within an AS. > [0], but I guess I=92m curious why collisions outside the AS would be > allowed? Shouldn=92t it be: >=20 > To prevent denial-of-service attacks against RPs, Subject Key > Identifier collisions are not permitted. Any BGPsec Router > Certificate that: > * references the same AS number in the Autonomous System > Identifier Delegation extension, > * has a different key, and > * has the same value in the Subject Key Identifier extension > as another otherwise valid certificate MUST NOT be > considered valid. Did you intend to leave that first bullet in place? With that bullet in place the first sentence doesn't match the rest (the first sentence says no collisions anywhere, while the rest says no collisions within an AS). Assuming you meant to drop that first bullet, I see a few issues with the wording: * If an easily exploitable weakness is found in SHA-1 (or whatever algorithm is chosen), then one organization can easily invalidate a cert from another organization. * It forces RPs to check that the SKI was properly computed. If RPs do not compute a SHA-1 hash to validate the SKI value, then it becomes trivial for an attacker to generate a certificate that invalidates someone else's certificate, even if SHA-1 remains strong. * It forces CAs to perform a global check for a colliding SKI before publishing the certificate. (also, the indentation for the last two lines is off; they should be shifted left 8 characters to line up with the text above the bulleted lis= t) -Richard >=20 > spt >=20 > [0] Full disclosure: I co-authored RFC 7093 "Additional Methods for > Generating Key Identifiers Values=94. From nobody Fri Aug 7 01:38:18 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A908E1ABD3F for ; Fri, 7 Aug 2015 01:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iVA9EprbzIck for ; Fri, 7 Aug 2015 01:38:14 -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 C4B691ABC10 for ; Fri, 7 Aug 2015 01:38:14 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1ZNdAI-000CKP-QC; Fri, 07 Aug 2015 10:38:11 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-64.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZNdAI-00063D-IE; Fri, 07 Aug 2015 10:38:10 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Bruijnzeels In-Reply-To: <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> Date: Fri, 7 Aug 2015 09:38:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.2102) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.0 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.1 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: 784d7acfe6559f2a0b602ec6519a071915185c8fa2d06f21c0e92dcb62340537 Archived-At: Cc: sidr wg list , "rhansen@bbn.com" Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 08:38:16 -0000 Hi Sean, Specifically on this point: > On Aug 7, 2015, at 12:52 AM, Sean Turner wrote: >=20 > I=92m all for switching to using a better hash algorithm to avoid = collisions, but why can=92t we just do it anytime we want? The SKI/AKI = fields are only ever generated by a CA so the RPs don=92t need to know = the algorithm used. This change would require certificates to be re-issued (or possibly keys = to be rolled) all the way down from Trust Anchors. When the parent CA = re-issues a certificate for the child CA with a new style SKI, then the = child will have to re-issue its products with a new AKI. This is not impossible, but not trivial either. Especially if a = delegated model is used. I am still not sure that avoiding collisions is that important in this = case. Proof of possession of the keys is verified through other means. A specific example: we have changed our validation algorithm to find the = most current *valid* MFT for a CA certificate by matching the SKI of the = CA certificate with the AKI of the MFT EE certificate. But we do check = that it's validly signed. So an accidental collision, or even a = maliciously crafted MFT (with a colliding AKI on its EE cert), should = not matter. But if I am missing a stronger reason I would like to know. I agree that if we need to change this it's better to address this = sooner rather than later. Tim= From nobody Fri Aug 7 03:35:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BF01AC44A for ; Fri, 7 Aug 2015 03:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 apIaMa1GoBLG for ; Fri, 7 Aug 2015 03:35:25 -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 209BD1AC408 for ; Fri, 7 Aug 2015 03:35:25 -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 1ZNezi-0005Lp-JO; Fri, 07 Aug 2015 10:35:23 +0000 Date: Fri, 07 Aug 2015 19:35:21 +0900 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@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] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 10:35:26 -0000 > This change would require certificates to be re-issued (or possibly > keys to be rolled) all the way down from Trust Anchors. When the > parent CA re-issues a certificate for the child CA with a new style > SKI, then the child will have to re-issue its products with a new AKI. > > This is not impossible, but not trivial either. Especially if a > delegated model is used. have we done a dnssec-v1? we should be able to change hashes without a flag day. if not, we need to think. randy From nobody Fri Aug 7 04:59:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417D31B2B46 for ; Fri, 7 Aug 2015 04:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kJUY7zYNjYtN for ; Fri, 7 Aug 2015 04:59:02 -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 F3C941B2AC4 for ; Fri, 7 Aug 2015 04:59:01 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1ZNgIc-0005LI-3F; Fri, 07 Aug 2015 13:58:58 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-207.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZNgIb-0006Cb-Sq; Fri, 07 Aug 2015 13:58:57 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 7 Aug 2015 12:58:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04BAA3C5-D44E-4DF2-97D4-0CC00A0E293A@ripe.net> References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> To: Randy Bush X-Mailer: Apple Mail (2.2102) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.0 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.1 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: 784d7acfe6559f2a0b602ec6519a0719d5d103e056f325fdeffcd89d38e6a478 Archived-At: Cc: sidr wg list Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 11:59:03 -0000 > On Aug 7, 2015, at 11:35 AM, Randy Bush wrote: >=20 >> This change would require certificates to be re-issued (or possibly >> keys to be rolled) all the way down from Trust Anchors. When the >> parent CA re-issues a certificate for the child CA with a new style >> SKI, then the child will have to re-issue its products with a new = AKI. >>=20 >> This is not impossible, but not trivial either. Especially if a >> delegated model is used. >=20 > have we done a dnssec-v1? we should be able to change hashes without = a > flag day. if not, we need to think. actually, thinking about this a bit longer now.. If both SHA-1 and SHA-256 are allowed (at least for a while) this can be = initiated by any CA that wants to make the change. Important bits are: - RFC6492 uses SKIs for revoke requests - The AKI of products issued by a CA should match their SKI I guess that the easiest way to make this work is a key roll. Create a = new key, request a certificate for it with the new SKI, re-issue the = products with the new key, and finally revoke the old key (using the old = style SKI). It's still work, but not as bad as I previously painted. From nobody Fri Aug 7 09:07:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B51B2EBD for ; Fri, 7 Aug 2015 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GZQF_zFTwq6t for ; Fri, 7 Aug 2015 09:07:38 -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 B174E1A90E7 for ; Fri, 7 Aug 2015 09:07:38 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:41869) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZNkBF-000ICM-Gu for sidr@ietf.org; Fri, 07 Aug 2015 12:07:37 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 3713A40022 Message-ID: <55C4D7C8.4000401@bbn.com> Date: Fri, 07 Aug 2015 12:07:36 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: sidr@ietf.org References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 16:07:45 -0000 On 2015-08-07 06:35, Randy Bush wrote: >> This change would require certificates to be re-issued (or possibly >> keys to be rolled) all the way down from Trust Anchors. When the >> parent CA re-issues a certificate for the child CA with a new style >> SKI, then the child will have to re-issue its products with a new AKI. >> >> This is not impossible, but not trivial either. Especially if a >> delegated model is used. >=20 > have we done a dnssec-v1? we should be able to change hashes without a > flag day. if not, we need to think. We cannot change the SKI algorithm without a flag day. Fortunately, if we prohibit CAs from publishing router certs with colliding SKIs within an AS (as proposed in my original email), we won't ever need to. The following is an enumeration of some important points about the SKI that hopefully makes it easy to understand why my proposed change should be sufficient (credit for the idea goes to Matt Lepinski; I only came up with the specific wording): 1. The SKI length is currently fixed at 160 bits: * RFC6487 (and rfc6487bis) says 160-bit SHA1 * the rpki-rtr protocol has a fixed-length 160-bit SKI field * the BGPsec protocol has a fixed-length 160-bit SKI field 2. The SKI does not contain an algorithm identifier OID, so there is no way to communicate to RPs that a different algorithm was used to produce the SKI. 3. SKI collisions must be prevented to keep an attacker from temporarily disabling BGPsec. If collisions were not prevented, I believe the attacker could launch the following attack: a. generate tons of certificates with different keys but the same SKI b. publish the certificates c. send a syntactically correct BGPsec update message where: * the BGPsec_Path entries are made up (including invalid signatures) * the most recent entry uses the colliding SKI and the attacker's AS number but a bad signature d. sit back and enjoy a period of time where routers use the invalid route while validation is pending The above attack works because routers will likely use the update message as if it was valid until the cryptographic operations determine otherwise (see bgpsec-protocols section 5 paragraph 2). Because of the numerous colliding SKIs, it will take routers a long time to exhaustively check every matching certificate before it reaches the conclusion that the signature was not produced by any of the matching certificates. 4. The only mechanism we have in place to prevent SKI collisions is the SKI algorithm itself. 5. Because of points #3 and #4 above, RPs must validate the SKI in a router certificate. If RPs blindly trusted CAs to correctly produce the correct SKI value, then it would be trivial for an attacker to produce thousands of certificates with colliding SKI values (e.g., just fill in the SKI with all zeros). 6. Because of points #2 and #5 above, we can't change the SKI algorithm without a flag day. 7. Because of points #3, #4, and #6 above, BGPsec's security is tied to the security of the unchangeable SKI algorithm. 8. SHA-1 is believed to be sufficient at the moment for preventing SKI collisions, even with malicious actors. 9. Someone might eventually discover a way to easily produce SHA-1 collisions. If so, SHA-1 would no longer be sufficient for preventing SKI collisions with malicious actors. 10. If we added a separate mechanism to prevent SKI collisions, it would not matter how the SKI was generated. The SKI (currently) serves no security-relevant function other than quick key lookup, so if another mechanism prevented SKI collisions then we could switch to a cryptographically insecure algorithm like CRC64 (though I wouldn't recommend it). Point #7 is what concerns me, but point #10 gives us an easy way out. The proposed change in my original email adds a separate mechanism to prevent SKI collisions. By adopting the proposed change, RPs would invalidate all router certs with colliding SKIs (within an AS), thus breaking our dependency on the security of SHA-1. So that you don't have to go find my original email, I've copied the proposal below. Again, credit goes to Matt Lepinksi for the idea. Add the following to the end of Section 3 in draft-ietf-sidr-bgpsec-pki-profiles: o To prevent denial-of-service attacks against RPs, Subject Key Identifier collisions within an AS are not permitted. Any BGPsec Router Certificate that: * references the same AS number in the Autonomous System Identifier Delegation extension, * has a different key, and * has the same value in the Subject Key Identifier extension as another otherwise valid certificate MUST NOT be considered valid. -Richard From nobody Tue Aug 11 07:43:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1118C1A8F43 for ; Tue, 11 Aug 2015 07:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=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 CvoxZseBoas0 for ; Tue, 11 Aug 2015 07:43:46 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.49.40]) (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 DF9FF1A8BBF for ; Tue, 11 Aug 2015 07:43:45 -0700 (PDT) Received: by gateway20.websitewelcome.com (Postfix, from userid 500) id 74A4A8D3FA626; Tue, 11 Aug 2015 09:43:45 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 644C48D3FA5C0 for ; Tue, 11 Aug 2015 09:43:45 -0500 (CDT) Received: from [96.231.216.201] (port=55428 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZPAmG-000GYU-Eb; Tue, 11 Aug 2015 09:43:44 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Tue, 11 Aug 2015 10:43:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52B6D93F-0AB3-4705-8374-2A729B240586@ieca.com> References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> To: George Michaelson X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.216.201 X-Exim-ID: 1ZPAmG-000GYU-Eb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.216.201]:55428 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: sidr wg list , Richard Hansen Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 14:43:49 -0000 (I see there=92s been some more mail on this thread so hopefully I won=92t= contradict myself later :/ ) No fear about harming SHA256 deployment! We=92re already using it for = the hash+sigs of the Manifest, ROAs, RPKI-certs (both for RPKI and = BGPsec). On Aug 06, 2015, at 20:33, George Michaelson wrote: > Can you give me some indication at what level of operation a SHA1 over = the public key risks colliding? 0.001? 0.00001? >=20 > I don't want to impede progress if SHA256 is sensible, but I have a = feeling this is a risk almost at the noise floor. Since its per-CA, the = CA is presumed to have to hand a complete set of all the active keys its = signed over, and presumably could say: "damn. collide" -not that it has = much choice about what to do, to get over this. >=20 > Its possible we're just hunting more 0.000s down the road. This made me chuckle, because in some sense that=92s what we always do = while cryptographers are chopping=92/slayin=92 zeros ;) > There are <1m discrete prefixes in the current routing system, and = less than 256,000 actors in this specific (non-BGP router key, not path = key) space of allocations and assignments (we're only just walking into = 4 byte ASN territory so the real number of actors is very possibly far = smaller, but its more than the total count of ASN since many prefix = holders in Asia don't have ASN and sign ROA over somebody else's ASN, = but clearly, its bounded by the prefix count. So I feel ok saying it = lies between 64k and 1m) >=20 > There is a minimum break-out of 5-way near the top, lets assume they = equi position (they don't) and say between 16k and 256k per top CA, = thats me asking you if a SHA1 hash over the keys, in 256,000 sign-overs, = is likely to collide. Anyone else has far fewer. Most CA has less than = 10000 and very probably less than 1000 things to sign over. Even the = APNIC flat world has less than 256k things to sign over. >=20 > I know; I could spin up the dice (again) >=20 > I did this for about 60,000 when I first tested things before we had a = design. I did not even collide in the crude OpenSSL hash name model, let = alone the SKI hash. >=20 > Pragmatism is not good. I'm fine with a respin to put this to SHA256 = but might we not just want to say "...plus a -1 -2 -3 generational = qualifier should a collision occur" and avoid any risk? Starting with my usual caveat: I=92m not a cryptographer When talking about collisions, a hash algorithms are usually considered = to be about as strong as half the output length so for SHA-1 it=92s = 2^(160/2). But, there=92s been some attacks which RFC 6194 says got = down to 2^69 but assuming wikipedia is right it=92s down in the 2^63 = range. I guess I=92d have to leave it to you to decide whether that=92s = enough of a safety margin. I think Richard gives his opinion in point 8 of this msg: = https://mailarchive.ietf.org/arch/msg/sidr/SLhN-BAOzQmxn-7GmfWxIc2VrrQ spt > -G >=20 > On Thu, Aug 6, 2015 at 8:52 PM, Sean Turner wrote: >=20 > On May 22, 2015, at 10:55, Richard Hansen wrote: >=20 > > Hi all, > > > > A while back Sean Turner raised the idea of switching to SHA-256 for = the > > Subject Key Identifier while discussing rfc6487bis (see > > ). I see a couple of > > reasons to do this: > > > > * If/when additional weaknesses are found in SHA-1, 3rd party > > cryptographic libraries that implement SHA-1 may become hard to > > find. > > > > * If/when a serious weakness is found in SHA-1, someone might be > > able to exploit the weakness to attack some aspect of = RPKI/BGPsec. > > > > Thinking about the latter, I believe there is a = not-entirely-implausible > > attack that might justify a change: > > > > 1. An attacker uses a weakness in SHA-1 to generate a large number = of > > BGPsec router certificates for an AS, where each certificate has = a > > different key but the same SKI. > > > > 2. The attacker uses one of those certificates to generate a > > signature segment in the BGPsec_Path attribute, and sends the > > BGPsec Update message to a peer. > > > > 3. The peer starts the process of validating the signature segment > > generated by the attacker. Due to the numerous keys with the = same > > SKI, the peer is forced to test each of the attacker's keys one = by > > one until a match is found. This could take a considerable = amount > > of time. > > > > 4. While it is validating the signature, the peer processes all > > Update messages as if they were unsigned because there is not > > enough CPU available at the moment. The attacker has succeeded = in > > (temporarily) disabling BGPsec. > > > > One way to block the above attack is to use a stronger hash function > > (e.g., SHA-256) for the SKI. Unfortunately, because the SKI = extension > > doesn't have an algorithm identifier field, there's no way to switch > > without a flag day. > > > > We could make a proactive change now while deployment is low, but it > > would still be unpleasant. > > > > An alternative idea suggested by Matt Lepinski is to prohibit router > > certificate SKI collisions within an AS if the keys differ. In = other > > words, if there are two valid BGPsec router certs in the same AS = with > > different keys but the same SKI, then RPs MUST mark them both as > > invalid. Thanks to the RFC3779 checks, it would not be possible for > > someone in a different AS to invalidate your certs even if a = weakness in > > SHA-1 was discovered. > > > > So I propose we add something like the following to the end of = Section 3 > > in draft-ietf-sidr-bgpsec-pki-profiles: > > > > o To prevent denial-of-service attacks against RPs, Subject Key > > Identifier collisions within an AS are not permitted. Any > > BGPsec Router Certificate that: > > * references the same AS number in the Autonomous System > > Identifier Delegation extension, > > * has a different key, and > > * has the same value in the Subject Key Identifier extension > > as another otherwise valid certificate MUST NOT be considered > > valid. > > > > We may also want to add something to rfc6487bis to invalidate a > > certificate if its SKI matches an ancestor (and the key differs), = though > > I can't think of a way to take advantage of such a collision at the = moment. > > > > Thoughts? > > > > Thanks, > > Richard >=20 > I=92m all for switching to using a better hash algorithm to avoid = collisions, but why can=92t we just do it anytime we want? The SKI/AKI = fields are only ever generated by a CA so the RPs don=92t need to know = the algorithm used. >=20 > What I am/was suggesting we do is make the following change in Section = 4.8.2/3 to RFC 6487: >=20 > OLD: >=20 > The Key Identifier used for resource certificates is the 160-bit > SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the > Subject Public Key, as described in Section 4.2.1.1/2 of [RFC5280]. >=20 > NEW: >=20 > The Key Identifier used for resource certificates is the 160-bit > SHA-256 hash of the value of the DER-encoded ASN.1 bit string of the > Subject Public Key, as described in Section 2 of [RFC7093]. >=20 > As far as you tweaks to the bgpsec-pki-profile draft, if we can do = these checks without calculating the AKI/SKI values I=92m all for this = [0], but I guess I=92m curious why collisions outside the AS would be = allowed? Shouldn=92t it be: >=20 > To prevent denial-of-service attacks against RPs, Subject Key > Identifier collisions are not permitted. Any BGPsec Router > Certificate that: > * references the same AS number in the Autonomous System > Identifier Delegation extension, > * has a different key, and > * has the same value in the Subject Key Identifier extension > as another otherwise valid certificate MUST NOT be > considered valid. >=20 > spt >=20 > [0] Full disclosure: I co-authored RFC 7093 "Additional Methods for = Generating Key Identifiers Values=94. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Tue Aug 11 10:09:25 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463341ACDD7 for ; Tue, 11 Aug 2015 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 03KQT_HcdDwO for ; Tue, 11 Aug 2015 10:09:21 -0700 (PDT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.181]) (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 BB6571ACDD0 for ; Tue, 11 Aug 2015 10:09:21 -0700 (PDT) Received: by gateway32.websitewelcome.com (Postfix, from userid 500) id 412AAD5C141BF; Tue, 11 Aug 2015 12:09:21 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 31036D5C14137 for ; Tue, 11 Aug 2015 12:09:21 -0500 (CDT) Received: from [96.231.216.201] (port=55919 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZPD3A-0000GN-9d; Tue, 11 Aug 2015 12:09:20 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <55C4D7C8.4000401@bbn.com> Date: Tue, 11 Aug 2015 13:09:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <55C4D7C8.4000401@bbn.com> To: Richard Hansen , sidr wg list X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.216.201 X-Exim-ID: 1ZPD3A-0000GN-9d X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.216.201]:55919 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:09:24 -0000 Saw you=92re earlier msg, but figured I=92d just reply to this one. On Aug 07, 2015, at 12:07, Richard Hansen wrote: > On 2015-08-07 06:35, Randy Bush wrote: >>> This change would require certificates to be re-issued (or possibly >>> keys to be rolled) all the way down from Trust Anchors. When the >>> parent CA re-issues a certificate for the child CA with a new style >>> SKI, then the child will have to re-issue its products with a new = AKI. >>>=20 >>> This is not impossible, but not trivial either. Especially if a >>> delegated model is used. >>=20 >> have we done a dnssec-v1? we should be able to change hashes without = a >> flag day. if not, we need to think. >=20 > We cannot change the SKI algorithm without a flag day. Fortunately, = if > we prohibit CAs from publishing router certs with colliding SKIs = within > an AS (as proposed in my original email), we won't ever need to. I think there=92s probably three-related topics: 1) avoiding collisions in BGPsec, 2) chaining the way SKIs are generated for BGPsec certificates/messages, = and 3) changing the way we make KIs for the entire RPKI. I think what Richard and I are going back and forth about is #1, but = others (including myself) seemed to be discussing #3 and I=92m sure I = was thinking about #2. I agree with Randy that if we can=92t change the = algorithm used to generate KIs without a flag-day, then I think we need = to think (more on this at the end). > The following is an enumeration of some important points about the SKI > that hopefully makes it easy to understand why my proposed change = should > be sufficient (credit for the idea goes to Matt Lepinski; I only came = up > with the specific wording): >=20 > 1. The SKI length is currently fixed at 160 bits: >=20 > * RFC6487 (and rfc6487bis) says 160-bit SHA1 > * the rpki-rtr protocol has a fixed-length 160-bit SKI field > * the BGPsec protocol has a fixed-length 160-bit SKI field Excellent - three of the example methods for defining a key identifier = in RFC 7093 are 160-bit outputs: The keyIdentifier is composed of the leftmost 160-bits of the SHA-* hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). Where * is 256, 384, and 512. I think this helps out somewhat on topics #2 and #3 because we=92d not = have to change a bunch of other drafts to make the SKIs fit. > 2. The SKI does not contain an algorithm identifier OID, so there is > no way to communicate to RPs that a different algorithm was used > to produce the SKI. There=92s also the fourth option from RFC 7093, which is: The keyIdentifier is composed of the hash of the DER encoding of the SubjectPublicKeyInfo value The SPKI does include the algorithm ID. > 3. SKI collisions must be prevented to keep an attacker from > temporarily disabling BGPsec. If collisions were not prevented, > I believe the attacker could launch the following attack: >=20 > a. generate tons of certificates with different keys but the > same SKI > b. publish the certificates > c. send a syntactically correct BGPsec update message where: > * the BGPsec_Path entries are made up (including invalid > signatures) > * the most recent entry uses the colliding SKI and the > attacker's AS number but a bad signature > d. sit back and enjoy a period of time where routers use the > invalid route while validation is pending >=20 > The above attack works because routers will likely use the update > message as if it was valid until the cryptographic operations > determine otherwise (see bgpsec-protocols section 5 paragraph 2). > Because of the numerous colliding SKIs, it will take routers a > long time to exhaustively check every matching certificate before > it reaches the conclusion that the signature was not produced > by any of the matching certificates. >=20 > 4. The only mechanism we have in place to prevent SKI collisions is > the SKI algorithm itself. >=20 > 5. Because of points #3 and #4 above, RPs must validate the SKI in a > router certificate. If RPs blindly trusted CAs to correctly > produce the correct SKI value, then it would be trivial for an > attacker to produce thousands of certificates with colliding SKI > values (e.g., just fill in the SKI with all zeros). >=20 > 6. Because of points #2 and #5 above, we can't change the SKI > algorithm without a flag day. >=20 > 7. Because of points #3, #4, and #6 above, BGPsec's security is tied > to the security of the unchangeable SKI algorithm. >=20 > 8. SHA-1 is believed to be sufficient at the moment for preventing > SKI collisions, even with malicious actors. >=20 > 9. Someone might eventually discover a way to easily produce SHA-1 > collisions. If so, SHA-1 would no longer be sufficient for > preventing SKI collisions with malicious actors. >=20 > 10. If we added a separate mechanism to prevent SKI collisions, it > would not matter how the SKI was generated. The SKI (currently) > serves no security-relevant function other than quick key lookup, > so if another mechanism prevented SKI collisions then we could > switch to a cryptographically insecure algorithm like CRC64 > (though I wouldn't recommend it). >=20 > Point #7 is what concerns me, but point #10 gives us an easy way out. > The proposed change in my original email adds a separate mechanism to > prevent SKI collisions. By adopting the proposed change, RPs would > invalidate all router certs with colliding SKIs (within an AS), thus > breaking our dependency on the security of SHA-1. >=20 > So that you don't have to go find my original email, I've copied the > proposal below. Again, credit goes to Matt Lepinksi for the idea. >=20 > Add the following to the end of Section 3 in > draft-ietf-sidr-bgpsec-pki-profiles: >=20 > o To prevent denial-of-service attacks against RPs, Subject Key > Identifier collisions within an AS are not permitted. Any > BGPsec Router Certificate that: >=20 > * references the same AS number in the Autonomous System > Identifier Delegation extension, > * has a different key, and > * has the same value in the Subject Key Identifier extension >=20 > as another otherwise valid certificate MUST NOT be considered > valid. >=20 > -Richard Okay so I want to agree. But, I=92m still trying to grok something you = sent in an earlier msg = (https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI) = that I think is related when you said: RPs would not have to calculate/validate the SKI value; they would = only need to check for collisions within an AS. The first bit, says RPs don=92t have to calculate/validate the SKI; I = interpret the phrase =93the SKI value=94 to mean =93any SKI values - = ever=94 and I like that. But, the next part confuses me because I don=92t= get how RPs (assuming the =93they=94 is an RP) do this check without = calculating/validating an SKI? On topic #2 (changes to BGPsec SKI generation): I actually think we can just change the SKI generation method: BGPsec = certificate are leaf certificates so there=92s no AKI/SKI matching = issue, we=92re updating RFC 6487 to add differences anyway, and SKIs are = only used in BGPsec messages. If I wanted to fix this for the future = (and this is just off the top of my head), I=92d probably say something = like the following to bgpsec-pki-profiles in a new SKI section: The keyIdentifier is composed of the leftmost 160-bits of the hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). The hash algorithm used is same one used when generating BGPsec messages; see Section 2 of [I-D.sidr-bgpsec-algs]. It=92s SHA-256 now, but if BGPsec gets updated to be supercool-alg, then = supercool-alg would be the algorithm used. On topic #3: Assuming we are willing to bite off generating KIs RPKI-wide, can we do = as Tim suggested in his email = (https://mailarchive.ietf.org/arch/msg/sidr/3H8Q7zT4t06lZXHx_iD3N188U2I) = knowing that we=92ve got an example method from RFC-7093 that is 160-bit = in length? Here=92s a train of thought: RFC 6497 says this in s4: Where a field value is specified here, this value MUST be used in conforming resource certificates. and s7.2 has this: 3. The certificate contains all fields that MUST be present, as defined by this specification, and contains values for selected fields that are defined as allowable values by this specification. and s9 has the following: If the resource certificate profile is changed in the future, e.g., by adding a new extension or changing the allowed set of name attributes or encoding of these attributes, ... followed by a bunch of procedures. This train of thought makes me sad. So without trying to sugar coat this at all: can we make a change akin = to what Tim suggested without having to invoke all of the procedures in = s9? spt= From nobody Tue Aug 11 12:12:09 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EED11AD1EC for ; Tue, 11 Aug 2015 12:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uHw3it-6cHMM for ; Tue, 11 Aug 2015 12:12:04 -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 9E6221AD1C3 for ; Tue, 11 Aug 2015 12:12:04 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:42644) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZPExu-000KfI-Hl; Tue, 11 Aug 2015 15:12:02 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 3FCC63FEDB Message-ID: <55CA4901.4010007@bbn.com> Date: Tue, 11 Aug 2015 15:12:01 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Sean Turner , sidr wg list References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <55C4D7C8.4000401@bbn.com> <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> In-Reply-To: <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 19:12:08 -0000 On 2015-08-11 13:09, Sean Turner wrote: > Saw you=92re earlier msg, but figured I=92d just reply to this one. >=20 > On Aug 07, 2015, at 12:07, Richard Hansen wrote: >=20 >> On 2015-08-07 06:35, Randy Bush wrote: >>>> This change would require certificates to be re-issued (or possibly >>>> keys to be rolled) all the way down from Trust Anchors. When the >>>> parent CA re-issues a certificate for the child CA with a new style >>>> SKI, then the child will have to re-issue its products with a new AK= I. >>>> >>>> This is not impossible, but not trivial either. Especially if a >>>> delegated model is used. >>> >>> have we done a dnssec-v1? we should be able to change hashes without= a >>> flag day. if not, we need to think. >> >> We cannot change the SKI algorithm without a flag day. Fortunately, i= f >> we prohibit CAs from publishing router certs with colliding SKIs withi= n >> an AS (as proposed in my original email), we won't ever need to. >=20 > I think there=92s probably three-related topics: >=20 > 1) avoiding collisions in BGPsec, >=20 > 2) chaining the way SKIs are generated for BGPsec certificates/messages= , and >=20 > 3) changing the way we make KIs for the entire RPKI. >=20 > I think what Richard and I are going back and forth about is #1, Yes. > but others (including myself) seemed to be discussing #3 Yes, with me claiming that we don't need to do #3 if we do #1. (I still think that topic #3 is a good idea, but that can happen separately from/in addition to topic #1.) > and I=92m sure I was thinking about #2. Ah, interesting. I hadn't considered that option. It would be considerably easier to change SKIs for just BGPsec stuff than to change SKIs for all of RPKI. > I agree with Randy that if we can=92t change > the algorithm used to generate KIs without a flag-day, then I think > we need to think (more on this at the end). >=20 >> The following is an enumeration of some important points about the SKI >> that hopefully makes it easy to understand why my proposed change shou= ld >> be sufficient (credit for the idea goes to Matt Lepinski; I only came = up >> with the specific wording): >> >> 1. The SKI length is currently fixed at 160 bits: >> >> * RFC6487 (and rfc6487bis) says 160-bit SHA1 >> * the rpki-rtr protocol has a fixed-length 160-bit SKI field >> * the BGPsec protocol has a fixed-length 160-bit SKI field >=20 > Excellent - three of the example methods for defining a key > identifier in RFC 7093 are 160-bit outputs: >=20 > The keyIdentifier is composed of the leftmost 160-bits of the > SHA-* hash of the value of the BIT STRING subjectPublicKey > (excluding the tag, length, and number of unused bits). >=20 > Where * is 256, 384, and 512. Ah, OK. I hadn't looked at RFC 7093 until just now. So, if we figure out a way to support SKI hash algorithm flexibility (topics #2 and #3) but keep the selected hash algorithm's output truncated to 160 bits, then we no longer have to worry about attacks against a particular hash algorithm; we only have to worry about whether 160 bits will always be enough. >=20 > I think this helps out somewhat on topics #2 and #3 because we=92d not > have to change a bunch of other drafts to make the SKIs fit. Agreed. >=20 >> 2. The SKI does not contain an algorithm identifier OID, so there is >> no way to communicate to RPs that a different algorithm was used >> to produce the SKI. >=20 > There=92s also the fourth option from RFC 7093, which is: >=20 > The keyIdentifier is composed of the hash of the DER encoding of > the SubjectPublicKeyInfo value What does "the hash" mean in this fourth option? Is it flexible? If so, how is the selected hash function communicated to RPs? >=20 > The SPKI does include the algorithm ID. But that's the algorithm ID for the key, not a hash algorithm. >=20 >> 3. SKI collisions must be prevented to keep an attacker from >> temporarily disabling BGPsec. If collisions were not prevented, >> I believe the attacker could launch the following attack: >> >> a. generate tons of certificates with different keys but the >> same SKI >> b. publish the certificates >> c. send a syntactically correct BGPsec update message where: >> * the BGPsec_Path entries are made up (including invalid >> signatures) >> * the most recent entry uses the colliding SKI and the >> attacker's AS number but a bad signature >> d. sit back and enjoy a period of time where routers use the >> invalid route while validation is pending >> >> The above attack works because routers will likely use the update >> message as if it was valid until the cryptographic operations >> determine otherwise (see bgpsec-protocols section 5 paragraph 2). >> Because of the numerous colliding SKIs, it will take routers a >> long time to exhaustively check every matching certificate before >> it reaches the conclusion that the signature was not produced >> by any of the matching certificates. >> >> 4. The only mechanism we have in place to prevent SKI collisions is >> the SKI algorithm itself. >> >> 5. Because of points #3 and #4 above, RPs must validate the SKI in a >> router certificate. If RPs blindly trusted CAs to correctly >> produce the correct SKI value, then it would be trivial for an >> attacker to produce thousands of certificates with colliding SKI >> values (e.g., just fill in the SKI with all zeros). >> >> 6. Because of points #2 and #5 above, we can't change the SKI >> algorithm without a flag day. >> >> 7. Because of points #3, #4, and #6 above, BGPsec's security is tied >> to the security of the unchangeable SKI algorithm. >> >> 8. SHA-1 is believed to be sufficient at the moment for preventing >> SKI collisions, even with malicious actors. >> >> 9. Someone might eventually discover a way to easily produce SHA-1 >> collisions. If so, SHA-1 would no longer be sufficient for >> preventing SKI collisions with malicious actors. >> >> 10. If we added a separate mechanism to prevent SKI collisions, it >> would not matter how the SKI was generated. The SKI (currently) >> serves no security-relevant function other than quick key lookup, >> so if another mechanism prevented SKI collisions then we could >> switch to a cryptographically insecure algorithm like CRC64 >> (though I wouldn't recommend it). >> >> Point #7 is what concerns me, but point #10 gives us an easy way out. >> The proposed change in my original email adds a separate mechanism to >> prevent SKI collisions. By adopting the proposed change, RPs would >> invalidate all router certs with colliding SKIs (within an AS), thus >> breaking our dependency on the security of SHA-1. >> >> So that you don't have to go find my original email, I've copied the >> proposal below. Again, credit goes to Matt Lepinksi for the idea. >> >> Add the following to the end of Section 3 in >> draft-ietf-sidr-bgpsec-pki-profiles: >> >> o To prevent denial-of-service attacks against RPs, Subject Key >> Identifier collisions within an AS are not permitted. Any >> BGPsec Router Certificate that: >> >> * references the same AS number in the Autonomous System >> Identifier Delegation extension, >> * has a different key, and >> * has the same value in the Subject Key Identifier extension >> >> as another otherwise valid certificate MUST NOT be considered >> valid. >> >> -Richard >=20 > Okay so I want to agree. But, I=92m still trying to grok something you > sent in an earlier msg > (https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI= ) > that I think is related when you said: >=20 > RPs would not have to calculate/validate the SKI value; they would on= ly > need to check for collisions within an AS. >=20 > The first bit, says RPs don=92t have to calculate/validate the SKI; I > interpret the phrase =93the SKI value=94 to mean =93any SKI values - ev= er=94 > and I like that. But, the next part confuses me because I don=92t get > how RPs (assuming the =93they=94 is an RP) do this check without > calculating/validating an SKI? If the change I proposed is adopted, then I believe (but am not 100% certain) that the following RP validation procedure is secure: 1. Perform the usual RPKI checks, but don't bother validating whether the SKI value in router certificates is indeed the SHA-1 hash of the relevant bits 2. Group all router certificates that pass step #1 by AS number 3. For each AS group of router certificates, check to see if any two or more certificates in the group have an identical SKI value. If so, invalidate those certificates. The above procedure does not require RPs to compute the SHA-1 hash, yet it's secure against an attacker who wants to create colliding certs to overwhelm routers with computational work. This validation procedure would enable CAs to use a simple counter or any other algorithm for the SKI value because the RPs wouldn't be validating the SKI. That's OK -- the security of BGPsec would not be compromised (I think). Now consider the case where the change I proposed is not adopted (the current situation). In this case, RPs must compute the SHA-1 hash to validate the SKI value. Otherwise, it would be trivial for an attacker to generate multiple router certs with colliding SKIs. Even validating the SKI might not be enough if a significant weakness is found in SHA-1. >=20 >=20 > On topic #2 (changes to BGPsec SKI generation): >=20 > I actually think we can just change the SKI generation method: BGPsec > certificate are leaf certificates so there=92s no AKI/SKI matching > issue, we=92re updating RFC 6487 to add differences anyway, and SKIs > are only used in BGPsec messages. If I wanted to fix this for the > future (and this is just off the top of my head), I=92d probably say > something like the following to bgpsec-pki-profiles in a new SKI > section: >=20 > The keyIdentifier is composed of the leftmost 160-bits of the > hash of the value of the BIT STRING subjectPublicKey > (excluding the tag, length, and number of unused bits). > The hash algorithm used is same one used when generating > BGPsec messages; see Section 2 of [I-D.sidr-bgpsec-algs]. >=20 > It=92s SHA-256 now, but if BGPsec gets updated to be supercool-alg, > then supercool-alg would be the algorithm used. This sounds like a good idea to me. Given that we may want to tackle topic #3 at some point in the future, I would prefer it if the above wording included an algorithm OID in the router cert SKI extension. That might mean changing the BGPsec protocol and rpki-rtr documents to make it clear that the 160 bit SKI fields do not include the OID, but it would provide uniformity between router certs and other RPKI certs in a hypothetical post-topic-#3 world. >=20 >=20 > On topic #3: >=20 > Assuming we are willing to bite off generating KIs RPKI-wide, can we > do as Tim suggested in his email > (https://mailarchive.ietf.org/arch/msg/sidr/3H8Q7zT4t06lZXHx_iD3N188U2I= ) > knowing that we=92ve got an example method from RFC-7093 that is > 160-bit in length? Here=92s a train of thought: >=20 > RFC 6497 says this in s4: >=20 > Where a field value is specified > here, this value MUST be used in conforming resource certificates. >=20 > and s7.2 has this: >=20 > 3. The certificate contains all fields that MUST be present, as > defined by this specification, and contains values for > selected fields that are defined as allowable values by this > specification. >=20 > and s9 has the following: >=20 > If the resource certificate profile is changed in the future, e.g., > by adding a new extension or changing the allowed set of name > attributes or encoding of these attributes, ... >=20 > followed by a bunch of procedures. >=20 > This train of thought makes me sad. >=20 > So without trying to sugar coat this at all: can we make a change > akin to what Tim suggested without having to invoke all of the > procedures in s9? Unfortunately no, with the disclaimer that I haven't really thought about it in depth. Because of the challenge of accomplishing topic #3, I would like start with the much simpler topic #1. Note that I'm not opposed to tackling #3, but the amount of work involved means that I'd like to get topic #1, and possibly topic #2, out of the way first. -Richard >=20 > spt From nobody Tue Aug 11 12:49:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BBF1AD49B for ; Tue, 11 Aug 2015 12:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MrrmHa1O1Ykc for ; Tue, 11 Aug 2015 12:48:58 -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 B61C71AD2F6 for ; Tue, 11 Aug 2015 12:48:56 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50734 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZPFXa-000385-U6 for sidr@ietf.org; Tue, 11 Aug 2015 15:48:55 -0400 To: sidr@ietf.org References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <55C4D7C8.4000401@bbn.com> <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> From: Stephen Kent Message-ID: <55CA51A6.1070209@bbn.com> Date: Tue, 11 Aug 2015 15:48:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> Content-Type: multipart/alternative; boundary="------------080301090208030903070603" Archived-At: Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 19:49:00 -0000 This is a multi-part message in MIME format. --------------080301090208030903070603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sean, > ... > Okay so I want to agree. But, Im still trying to grok something you sent in an earlier msg (https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI) that I think is related when you said: > > RPs would not have to calculate/validate the SKI value; they would only > need to check for collisions within an AS. No, and yes. I was chatting with Sandy and noted that a compliant RP does have to check that the SKI is the has of the public key, as per RFC 6487. That RFC says that KI values are computed as SHA-1 hashes of the (relevant) public key (section 4.8.2), and that RPs are supposed to confirm this, as per item #3 in Section 7.2: The certificate contains all fields that MUST be present, as defined by this specification, *a**nd contains values for** ** selected fields that are **defined as allowable values by this** ** specification. *This requirement is more stringent than what 5280 mandates. 5280 imposes requirements on CAs wrt cert generation, but does not require that RPs verify that a CA has adhered to these requirements. This one-sided approach has not worked out well in the PKI arena in general, which is why the RPKI adopted a more symmetric model, i.e., specify what each CA is supposed to do, and then have every RP verify that the CAs are doing what they are supposed to. So, we can't change the hash alg used to compute KIs in the RPKI, without a lot of effort, something you alluded to later in your message. Steve --------------080301090208030903070603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Sean,

... 
Okay so I want to agree.  But, Im still trying to grok something you sent in an earlier msg (https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI) that I think is related when you said:

  RPs would not have to calculate/validate the SKI value; they would only
  need to check for collisions within an AS.
No, and yes.

I was chatting with Sandy and noted that a compliant RP does have to check that the
SKI is the has of the public key, as per RFC 6487. That RFC says that KI values are computed
as SHA-1 hashes of the (relevant) public key (section 4.8.2), and that RPs are supposed to
confirm this, as per item #3 in Section 7.2:

The certificate contains all fields that MUST be present, as
defined by this specification, and contains values for
 selected fields that are defined as allowable values by this
 specification.

This requirement is more stringent than what 5280 mandates. 5280 imposes requirements
on CAs wrt cert generation, but does not require that RPs verify that a CA has adhered
to these requirements. This one-sided approach has not worked out well in the PKI arena
in general, which is why the RPKI adopted a more symmetric model, i.e., specify what
each CA is supposed to do, and then have every RP verify that the CAs are doing what they
are supposed to.

So, we can't change the hash alg used to compute KIs in the RPKI, without a lot of effort,
something you alluded to later in your message.

Steve

--------------080301090208030903070603-- From nobody Tue Aug 11 16:59:08 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B339E1A0141 for ; Tue, 11 Aug 2015 16:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5hchVEpFAlUq for ; Tue, 11 Aug 2015 16:59:05 -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 C57C81A0120 for ; Tue, 11 Aug 2015 16:59:05 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:42728) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZPJRY-000Q0n-CS; Tue, 11 Aug 2015 19:58:56 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 345973FED5 Message-ID: <55CA8C3F.5050402@bbn.com> Date: Tue, 11 Aug 2015 19:58:55 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Stephen Kent References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <55C4D7C8.4000401@bbn.com> <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> <55CA51A6.1070209@bbn.com> In-Reply-To: <55CA51A6.1070209@bbn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 23:59:07 -0000 On 2015-08-11 15:48, Stephen Kent wrote: > Sean, >=20 >> ... >> Okay so I want to agree. But, I=92m still trying to grok something >> you sent in an earlier msg >> (https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqP= I) >> that I think is related when you said: >> >> RPs would not have to calculate/validate the SKI value; they would o= nly >> need to check for collisions within an AS. > > No, and yes. >=20 > I was chatting with Sandy and noted that a compliant RP does have to=20 > check that the SKI is the hash of the public key, as per RFC 6487. > That RFC says that KI values are computed as SHA-1 hashes of the > (relevant) public key (section 4.8.2), and that RPs are supposed to=20 > confirm this, as per item #3 in Section 7.2: >=20 > The certificate contains all fields that MUST be present, as > defined by this specification, *and contains values for > selected fields that are defined as allowable values by this > specification.* >=20 > This requirement is more stringent than what 5280 mandates. 5280 > imposes requirements on CAs wrt cert generation, but does not require > that RPs verify that a CA has adhered to these requirements. This > one-sided approach has not worked out well in the PKI arena in > general, which is why the RPKI adopted a more symmetric model, i.e., > specify what each CA is supposed to do, and then have every RP verify > that the CAs are doing what they are supposed to. Yes, you're absolutely correct. I hadn't noticed that requirement until both you and Sean quoted it today. I did not intend to imply that RPs can or should stop validating the SKI value if the proposed change was accepted. Indeed, I think it is a good idea to require a strong hash algorithm and to require RPs to validate the value. What I meant to say is: If the proposed change was accepted, the ability to defend against the attack would no longer depend on validating the SKI; merely identifying and invalidating certs in an AS with colliding SKIs is sufficient. Similarly, when I said the following in : The above procedure does not require RPs to compute the SHA-1 hash, yet it's secure against an attacker who wants to create colliding certs to overwhelm routers with computational work. This validation procedure would enable CAs to use a simple counter or any other algorithm for the SKI value because the RPs wouldn't be validating the SKI. That's OK -- the security of BGPsec would not be compromised (I think). I didn't intend to imply that we should stop validating the SKI or switch to a weak algorithm, only that if we did so then I believe that the security of BGPsec would remain intact (assuming we adopted the proposed change). With apologies for the confusion, Richard From nobody Wed Aug 12 04:43:40 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9B61A90D5 for ; Wed, 12 Aug 2015 04:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fsY1j12_I-w9 for ; Wed, 12 Aug 2015 04:43:37 -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 49FD11A90F4 for ; Wed, 12 Aug 2015 04:43:37 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:35400 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZPURT-0007XA-TB; Wed, 12 Aug 2015 07:43:35 -0400 To: Richard Hansen References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <55C4D7C8.4000401@bbn.com> <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> <55CA51A6.1070209@bbn.com> <55CA8C3F.5050402@bbn.com> From: Stephen Kent Message-ID: <55CB3167.8080907@bbn.com> Date: Wed, 12 Aug 2015 07:43:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55CA8C3F.5050402@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 11:43:39 -0000 Richard, no problem. anyway, my comments may have been too strongly worded. If we feel that it's important for router certs to use a different hash alg, then the router cert profile can define which alg to use, as an explicit, profiled deviation from the RPKI cert profile. We can also revisit the RP requirement to check the SKI in a router cert if we feel that will be necessary to enable alg agility for router cert SKI values going forward. This is a separate cert profile, so we have options. Steve From nobody Wed Aug 12 05:07:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540B01B2C8F for ; Wed, 12 Aug 2015 05:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yK4_u8Hybrex for ; Wed, 12 Aug 2015 05:07:43 -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 B06031B2CCE for ; Wed, 12 Aug 2015 05:07:43 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1ZPUol-0000FJ-PL; Wed, 12 Aug 2015 14:07:40 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-152.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZPUol-0007iE-KE; Wed, 12 Aug 2015 14:07:39 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Bruijnzeels In-Reply-To: <55CA4901.4010007@bbn.com> Date: Wed, 12 Aug 2015 14:07:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29E7C995-455A-4B15-8D1C-62C297674775@ripe.net> References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <55C4D7C8.4000401@bbn.com> <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> <55CA4901.4010007@bbn.com> To: "rhansen@bbn.com" X-Mailer: Apple Mail (2.2102) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 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: 784d7acfe6559f2a0b602ec6519a0719f91efb98f46266f60eef0da521737074 Archived-At: Cc: sidr wg list Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 12:07:46 -0000 Hi, > On Aug 11, 2015, at 9:12 PM, Richard Hansen wrote: >=20 >> On topic #3: >>=20 >> Assuming we are willing to bite off generating KIs RPKI-wide, can we >> do as Tim suggested in his email >> = (https://mailarchive.ietf.org/arch/msg/sidr/3H8Q7zT4t06lZXHx_iD3N188U2I) >> knowing that we=92ve got an example method from RFC-7093 that is >> 160-bit in length? Here=92s a train of thought: >>=20 >> RFC 6497 says this in s4: >>=20 >> Where a field value is specified >> here, this value MUST be used in conforming resource certificates. >>=20 >> and s7.2 has this: >>=20 >> 3. The certificate contains all fields that MUST be present, as >> defined by this specification, and contains values for >> selected fields that are defined as allowable values by this >> specification. >>=20 >> and s9 has the following: >>=20 >> If the resource certificate profile is changed in the future, e.g., >> by adding a new extension or changing the allowed set of name >> attributes or encoding of these attributes, ... >>=20 >> followed by a bunch of procedures. >>=20 >> This train of thought makes me sad. >>=20 >> So without trying to sugar coat this at all: can we make a change >> akin to what Tim suggested without having to invoke all of the >> procedures in s9? >=20 > Unfortunately no, with the disclaimer that I haven't really thought > about it in depth. Because of the challenge of accomplishing topic = #3, > I would like start with the much simpler topic #1. Note that I'm not > opposed to tackling #3, but the amount of work involved means that I'd > like to get topic #1, and possibly topic #2, out of the way first. >=20 > -Richard Perfectly fine with me. I admit I was confused about the three different topics being discussed = here. Thank you Sean for clearing that up! And as I said, I am not convinced that #3 is necessary: I can see = advantages in terms of consistency, and possibly some day the = availability of SHA-1 support in libraries, but I don't see a strict = need at the moment. Add to that that this affects existing deployment = and it's not trivial. I am not convinced there is a case. In short I agree with Richard that it would be better to park tackling = #3. At least until #1 and #2 are resolved or there is a more convincing = argument to abandon SHA-1 here. Tim From nobody Fri Aug 14 02:19:42 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5D81A87E7 for ; Fri, 14 Aug 2015 02:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Uu5NQEF_76em for ; Fri, 14 Aug 2015 02:19: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 DAC4D1A87DF for ; Fri, 14 Aug 2015 02:19:39 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 273E328B0041 for ; Fri, 14 Aug 2015 05:19:39 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E79331F8035; Fri, 14 Aug 2015 05:19:38 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_F75B83D9-51F5-4AFA-A211-697CBC727F67"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 14 Aug 2015 05:19:24 -0400 Message-Id: <836BAC24-6986-465B-BC32-A9AA78AF9A28@tislabs.com> To: sidr wg list 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] IETF93 minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 09:19:41 -0000 --Apple-Mail=_F75B83D9-51F5-4AFA-A211-697CBC727F67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The minutes to IETF93 have been uploaded to the meeting materials site. = Many thanks to Sue and Richard for taking notes. (We had a remote = listener contributing to the etherpad as minutes taker!). And thanks to = Sam for making a first editing pass. https://www.ietf.org/proceedings/93/minutes/minutes-93-sidr Please do read and send corrections to the list. There are a few places where the minutes takers could not decipher the = announced names, so if you remember making a comment where the name is = not noted, you can identify yourself. There are several places where people were asked to add a comment or a = question to the list. Please do review the minutes and send any message = you promised to send. =97Sandy, speaking as one of the wg co-chairs --Apple-Mail=_F75B83D9-51F5-4AFA-A211-697CBC727F67 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 iQIcBAEBCgAGBQJVzbKoAAoJEHplpQeet0IZkbIP/2tpphSTwC3niN+WznxqaVjz /VvaFhJh1br/0cGArNkEgmwyYWCH/2gjyQEL44SHmRlbG2MRsYoerEOcUip9hAfM /7/otXG7LhciG5a5tqZbVncBEHcL88xmt4M90BVehHgmRPFrqAuD8S31v8q9sb4S qo/0b1TiFXmqsfv22d36hRHzqLOL/PkMIz6rgcIK38saT2Xw1AuqHdnFTXy5G9tw wdhN7h8pfLDdINd+mzvwa/E1niZXITTTvRUhjfFHhC+RPlSiv/CRG+Fs6u+zm8+u JkQXNUWOCxAT/TirrW/I689LnNb61CDTRrFY5XJMWStVrxBc/cKPOUyhz9mWJB4e FrHr1+Q9hGNg/ETv0AFCsjbN9Ju0005zVrpRd4UKePXPCd5csEfJaX2lUdFm+VnQ 6AHrdZ4ND/bc9tE9i8UGNUamHI1a++sMqFwXRjTNRAWPDk5mCAX0rI7/nhEbtMOt zxK4TLat0nSErv8+lcabdR8vQp2oOXlMWSyxkcwdNHAXfPpCCeYYLlfHKxZnI9HD FNbCvDknQ79owaa7KdCQEnvhXd4/hOsQbcgg7ngMnzaQHm2rObZ6fFYVfZFMhG3O y666oyhs9820OymipcJmtZODnZAp0PCcXm5JfBUcF9+LdnRuTFGE8O8X9wkvjU7J HiA54ILBu4uWjJS3/h2e =Z9I3 -----END PGP SIGNATURE----- --Apple-Mail=_F75B83D9-51F5-4AFA-A211-697CBC727F67-- From nobody Tue Aug 25 09:02:01 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9540C1B35AC for ; Tue, 25 Aug 2015 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_SOFTFAIL=0.665] autolearn=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 isARuqf-2-3t for ; Tue, 25 Aug 2015 09:01:59 -0700 (PDT) Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id 652001B359B for ; Tue, 25 Aug 2015 09:01:59 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 0EEA6395D16; Tue, 25 Aug 2015 09:01:59 -0700 (PDT) From: Michael Baer To: sidr X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [sidr] Update to BGPsec BIRD Implementation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 16:02:00 -0000 Hi all, I wanted to announce newer versions of BGPsec supporting code using BIRD: bgpsec-bird-client v1.0 and v0.6 of BGPsec support code for BIRD. They are available as a source tarballs at: http://bgpsec.tislabs.com The bgpsec-bird-client application has two main features. It uses the rpki-rtr protocol (http://datatracker.ietf.org/doc/rfc6810) via RTRlib (https://rpki.realmv6.org/trac/) to download RPKI ROAs and router keys and then loads them into a running BIRD router (e.g. rtr_roa_table). It also supports the RPKI-RTR-MIB (http://datatracker.ietf.org/doc/rfc6945/) using the Net-SNMP toolkit (http://www.net-snmp.org). The BGPsec supporting BIRD code is currently based on v1.4.5 of BIRD. The main changes from the last release is that the the lack of the configure directive, --enable-bgpsec, will remove most of the BGPsec related code at compile time (i.e. without the --enable-bgpsec, the compiled code will be the same as the standard BIRD v1.4.5). It currently supports draft version 12 of the BGPsec protocol specification. This is an ongoing project following the IETF's SIDR Working Group's RPKI/BGPsec work: http://datatracker.ietf.org/wg/sidr/charter/ http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ The code is still at the testing stage and should not be use used for production services. If any one wants to test the code, please feel free to email me any questions or bug reports. Thanks, Mike -- Michael Baer Parsons baerm@tislabs.com From nobody Tue Aug 25 15:46:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092161B2A6E for ; Tue, 25 Aug 2015 15:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 p7gZFLhDbOnC for ; Tue, 25 Aug 2015 15:46:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id BAE881B2BE4 for ; Tue, 25 Aug 2015 15:46:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 44588180472; Tue, 25 Aug 2015 15:45:52 -0700 (PDT) To: kent@bbn.com, achi@cs.unc.edu, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150825224552.44588180472@rfc-editor.org> Date: Tue, 25 Aug 2015 15:45:52 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, sidr@ietf.org, david@mandelberg.org Subject: [sidr] [Editorial Errata Reported] RFC7132 (4454) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 22:46:04 -0000 The following errata report has been submitted for RFC7132, "Threat Model for BGP Path Security". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7132&eid=4454 -------------------------------------- Type: Editorial Reported by: David Mandelberg Section: 1 Original Text ------------- PATHSEC is intended to address the concerns cited above, to provide significantly improved path security, which builds upon the route origination validation capability offered by use of the RPKI [RFC6810]. Corrected Text -------------- PATHSEC is intended to address the concerns cited above, to provide significantly improved path security, which builds upon the route origination validation capability offered by use of the RPKI [RFC6811]. Notes ----- I think this text should reference RFC6811 (origin validation), not RFC6810 (the rpki-rtr protocol). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7132 (draft-ietf-sidr-bgpsec-threats-09) -------------------------------------- Title : Threat Model for BGP Path Security Publication Date : February 2014 Author(s) : S. Kent, A. Chi Category : INFORMATIONAL Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Aug 25 16:34:51 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828BE1A8868 for ; Tue, 25 Aug 2015 16:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 l364kbKH8fLR for ; Tue, 25 Aug 2015 16:34:48 -0700 (PDT) Received: from uu.ops-netman.net (maild1.aptea.com [206.112.93.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237D01A884B for ; Tue, 25 Aug 2015 16:34:47 -0700 (PDT) Received: from mail.ops-netman.net (unknown [208.76.12.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by uu.ops-netman.net (Postfix) with ESMTPS id 7FA57C006B; Tue, 25 Aug 2015 23:34:46 +0000 (UTC) Received: from morrowc-glaptop4.roam.corp.google.com.ops-netman.net (71-15-232-160.dhcp.sffl.va.charter.com [71.15.232.160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id A9F968801A5; Tue, 25 Aug 2015 23:34:45 +0000 (UTC) Date: Tue, 25 Aug 2015 19:34:43 -0400 Message-ID: From: Chris Morrow To: RFC Errata System In-Reply-To: <20150825224552.44588180472@rfc-editor.org> References: <20150825224552.44588180472@rfc-editor.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: db3546@att.com, sidr@ietf.org, morrowc@ops-netman.net, sandy@tislabs.com, david@mandelberg.org Subject: Re: [sidr] [Editorial Errata Reported] RFC7132 (4454) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 23:34:49 -0000 This seems correct to me (the proposed change I mean) At Tue, 25 Aug 2015 15:45:52 -0700 (PDT), RFC Errata System wrote: > > The following errata report has been submitted for RFC7132, > "Threat Model for BGP Path Security". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7132&eid=4454 > > -------------------------------------- > Type: Editorial > Reported by: David Mandelberg > > Section: 1 > > Original Text > ------------- > PATHSEC is intended to address the concerns cited above, to provide > significantly improved path security, which builds upon the route > origination validation capability offered by use of the RPKI > [RFC6810]. > > Corrected Text > -------------- > PATHSEC is intended to address the concerns cited above, to provide > significantly improved path security, which builds upon the route > origination validation capability offered by use of the RPKI > [RFC6811]. > > Notes > ----- > I think this text should reference RFC6811 (origin validation), not RFC6810 (the rpki-rtr protocol). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7132 (draft-ietf-sidr-bgpsec-threats-09) > -------------------------------------- > Title : Threat Model for BGP Path Security > Publication Date : February 2014 > Author(s) : S. Kent, A. Chi > Category : INFORMATIONAL > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Tue Aug 25 17:38:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6427B1A8ABB for ; Tue, 25 Aug 2015 17:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 R0qkTglt4het for ; Tue, 25 Aug 2015 17:37:59 -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 91E361A894E for ; Tue, 25 Aug 2015 17:37:59 -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 1ZUOik-0003YK-8N; Wed, 26 Aug 2015 00:37:42 +0000 Date: Wed, 26 Aug 2015 09:37:39 +0900 Message-ID: From: Randy Bush To: RFC Errata System In-Reply-To: <20150825224552.44588180472@rfc-editor.org> References: <20150825224552.44588180472@rfc-editor.org> 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: db3546@att.com, sidr@ietf.org, morrowc@ops-netman.net, sandy@tislabs.com, david@mandelberg.org Subject: Re: [sidr] [Editorial Errata Reported] RFC7132 (4454) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 00:38:00 -0000 > I think this text should reference RFC6811 (origin validation), not > RFC6810 (the rpki-rtr protocol). sigh. the erratum is correct. randy From nobody Tue Aug 25 17:39:58 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9841A92E3 for ; Tue, 25 Aug 2015 17:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YZf0bK33ir20 for ; Tue, 25 Aug 2015 17:39:56 -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 2E8361A92DD for ; Tue, 25 Aug 2015 17:39:56 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:42104 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZUOkn-000KjL-Qr; Tue, 25 Aug 2015 20:39:49 -0400 To: Chris Morrow , RFC Errata System References: <20150825224552.44588180472@rfc-editor.org> From: Stephen Kent Message-ID: <55DD0AD5.4010406@bbn.com> Date: Tue, 25 Aug 2015 20:39:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: db3546@att.com, sidr@ietf.org, sandy@tislabs.com, david@mandelberg.org Subject: Re: [sidr] [Editorial Errata Reported] RFC7132 (4454) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 00:39:58 -0000 yes, I concur as well. Steve > This seems correct to me (the proposed change I mean) > > At Tue, 25 Aug 2015 15:45:52 -0700 (PDT), > RFC Errata System wrote: >> The following errata report has been submitted for RFC7132, >> "Threat Model for BGP Path Security". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7132&eid=4454 >> >> -------------------------------------- >> Type: Editorial >> Reported by: David Mandelberg >> >> Section: 1 >> >> Original Text >> ------------- >> PATHSEC is intended to address the concerns cited above, to provide >> significantly improved path security, which builds upon the route >> origination validation capability offered by use of the RPKI >> [RFC6810]. >> >> Corrected Text >> -------------- >> PATHSEC is intended to address the concerns cited above, to provide >> significantly improved path security, which builds upon the route >> origination validation capability offered by use of the RPKI >> [RFC6811]. >> >> Notes >> ----- >> I think this text should reference RFC6811 (origin validation), not RFC6810 (the rpki-rtr protocol). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7132 (draft-ietf-sidr-bgpsec-threats-09) >> -------------------------------------- >> Title : Threat Model for BGP Path Security >> Publication Date : February 2014 >> Author(s) : S. Kent, A. Chi >> Category : INFORMATIONAL >> Source : Secure Inter-Domain Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG From nobody Tue Aug 25 18:14:48 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BEA1A8A7C for ; Tue, 25 Aug 2015 18:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 YUVg0NbAFfDg for ; Tue, 25 Aug 2015 18:14:45 -0700 (PDT) Received: from nm9-vm2.access.bullet.mail.gq1.yahoo.com (nm9-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.37]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB041A8A5A for ; Tue, 25 Aug 2015 18:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1440551684; bh=nm3YZV3mCEpsfHIahPLK0oysAj5JvlvNQ5kINtr0Ffo=; h=Date:From:To:Subject:From:Subject; b=Q9EFKDAIvVpEotTDrG5xC/9IlYkJmNxIGR1DhY/1ml33ZIipwkmef3ZtsW7vV4EJTEVjffq2HdiyS356ARiQyVjOV1W7LXV/jm1OiUnZk46YiCVUnk3gTIWeeNO17153xWDmStYlidxkD81oG6hi9Azte87gWHRtmz+6LrSz0SZ1tYRB9e3Eq2rD9rr5uKTZXZxoYPaJ2zq6zBbL+FMWtDTPO+dbKHetWZ7vZ8NOGBPoNTXBC0jKVY9wrG5RFmdMUD3mx7pBKw6f43HnrT2W6O8pG1JAsdB3PK/fikRoHqwAO91umPl23aG183QlpaUPx1ytju1+t0QgtiBqKB0bPw== Received: from [216.39.60.166] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2015 01:14:44 -0000 Received: from [98.138.104.96] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2015 01:14:44 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 26 Aug 2015 01:14:44 -0000 X-Yahoo-Newman-Id: 392466.25972.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: d5o8OOAVM1mTQQfx6shBRhloqYzrHoWmOqcziH.V1EgsuZj lpEJGjbEjFsOCDxuavlTRqj13HdcEgAxGLY6zvKyt7niydmfFaVkIoTocCwf FcuDibGVKoGQtGTEGXHEB.YdiqUZ2kLqJPKmc1wFE07HcsE0rdG_0mwXOGUt duhqVeJ5K0jrrMCVhholheQmlf_mxrp_d88pWYazEVubCHtGmcpig.e1V8j9 3NuI7efV21r4F7AmXNkF0DWXupq7JULorjz3Fr6QpwC5xH5EAjQ1Q6i3bitr 4K.BA2jtT8Rr80bENa8R8zJmOXpcZ_ygcEyoHJymWRxYNbR5dil.2bVq_ftR u_qop3Yln0dXz4As4zOQtVhvyHs9hKZrQux2bC5ezs_HnJ7e9G4kLO6P1xPU WsW8Fp_15nMV5SZm4E0XiKhyLRGaMeR06YdmjrtSj1y7Y32Qf6mMIkwXSt.t TjKcLdGN5J1nmxURKMiNd1JeUWsdreZPpJTd53GQ.swssaDKORuE8moMqlT7 dAnUkWSefEw1.ExE2ZcDjjzJtqnQpWK9t_gJ1BCWdcI.z03eacdlvEO5mhtF xbHNf789K5KMStA-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id A3D8B1C6058 for ; Tue, 25 Aug 2015 21:14:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 25 Aug 2015 21:14:42 -0400 From: David Mandelberg To: Message-ID: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: [sidr] draft-dseomn-sidr-slurm adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 01:14:47 -0000 Hi all, As I mentioned at IETF 93, I think SLURM (https://tools.ietf.org/html/draft-dseomn-sidr-slurm-02) is in good shape for working group adoption. It's a relatively simple solution that supports two of the use cases from draft-ietf-sidr-lta-use-cases-03, and it replaces parts of draft-ietf-sidr-ltamgmt-08, which is in the process of being withdrawn. Chairs, please consider this a formal request to put out an adoption call, as Sandy requested during the last meeting. P.S. Does anybody know of a good soft drink distributor who could help me get this adopted at the beverage breaks too? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Aug 26 14:26:30 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FCC1B2DA7 for ; Wed, 26 Aug 2015 14:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 J-oKP5ayp8qF for ; Wed, 26 Aug 2015 14:26:27 -0700 (PDT) Received: from nm4-vm5.access.bullet.mail.bf1.yahoo.com (nm4-vm5.access.bullet.mail.bf1.yahoo.com [216.109.114.116]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666AC1B2BDF for ; Wed, 26 Aug 2015 14:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1440624386; bh=ThxMh+rWPcwbjcM3q6ZEiF9u24kx9hXgp8NNjq+r39M=; h=Date:From:To:Subject:From:Subject; b=XpuqWfJxw96LF6AB/H/Dhl0cHUX0qdXIceNeXqT6Ou0o23GQIKiIGCZQSkJS7dHb0dgfrkl43SWC1lz2GcrYgAu2LMfGcWtoiIr/SnGj4lWKQIVsM0DQwbPnZrzuJ6IgxjzVxJ8dmqyWRqmZRO1hp/JYT0j5XklekJ9msXiWhFQW3YKp48TTXuab2JyLJzn3xmNoqR8wPZeenHq0ciBNokqamkwIv2vqVen0xhiEpdrzF0YBBKVhha1+JSkQkW4z2idNiPNf8qYUKZVBip47tdRTHjpSCdSvGyOEXqqA9MQPmjUj2Nnf9L3LwGPaRVAoQeQhy/JTy6DYlms/dSSv3w== Received: from [66.196.81.159] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2015 21:26:26 -0000 Received: from [98.138.104.99] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2015 21:26:26 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 26 Aug 2015 21:26:26 -0000 X-Yahoo-Newman-Id: 489018.65989.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BgaGT48VM1mUoZ5oqhyqsyfzt9cs7WPP2oTvFxEzsmWz2GE rp.Xo8m3IHX1bKgn72Va.tYkZmRJs6zXX_XZ0bv.FgeNLjlpYS1vA0PvDooH hv1vUOSe5KYKrVmwckSpDwbVb_jTZWakNKWH99iZF6YEZOdzZ0FXK7qRCfPz WamISzFc0BCHiYdHYdmjnhwdX_i8lj.2GnqlkHCRD6HieAkNbP_QikpdnTYX OzYx4W_bd4jRL0MoE2JbaMjDyjCNZVxNbG1LzQqrpi7GneatvgK0ddxtmySa WZ6FIoSEE1bMWJ_vBXeHSdLV6bJu8S.prio9sXWRRicaOmfsJreSVj.054Me R1oHIJhNf3r8dMBlKMj1q8C4PhgZ_NaFi70tNiq14my.ey0MM5zimA8kPfu8 qAB1Dkdj29lWQoyNI0zZH8D21_RLycdLwDR6OjfLFwYR0Jlt4iDu4Yvh61eo mDzge4TUlmuFYwfbI2OLAbiuI2.Xxfx6ncDP1glqRY1GIjZE_dCWajYwBMJw QO4dSSIsTuv_w70olvCEMIGtnDnh2KRJ4K1td9w-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id B20131C6095 for ; Wed, 26 Aug 2015 17:26:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 26 Aug 2015 17:26:24 -0400 From: David Mandelberg To: Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 21:26:29 -0000 Hi all, I think I found an issue with draft-ietf-sidr-bgpsec-protocol-13's security guarantees. Apologies that I didn't catch this earlier, before WGLC ended. The security guarantee with the issue is in section 7.1, "For each AS in the path, a BGPsec speaker authorized by the holder of the AS number intentionally chose (in accordance with local policy) to propagate the route advertisement to the subsequent AS in the path." It appears that this guarantee will not always hold. Specifically, if two non-adjacent ASes conspire, and they are separated by a sequence of ASes that sign path data that they have not verified, then the conspiring ASes can violate the guarantee. The ASes that signed path data they didn't verify are behaving properly, since the spec says "In particular, the BGPsec attribute SHOULD NOT be removed even in the case where the BGPsec update message has not been that has not successfully validated." I have not yet been able to come up with a practical attack that uses this issue to do anything particularly bad, but I am concerned that one might exist. I think this problem might be fixed if we modify the protocol to sign all of the preceding signed data (rather than just the immediate, previous signature). Thoughts? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Aug 26 17:20:30 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384241A1B57 for ; Wed, 26 Aug 2015 17:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MjUdTJho7l6I for ; Wed, 26 Aug 2015 17:20: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 4A9241A1AFB for ; Wed, 26 Aug 2015 17:20:24 -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 1ZUkvV-0008BQ-Rz; Thu, 27 Aug 2015 00:20:22 +0000 Date: Thu, 27 Aug 2015 09:20:20 +0900 Message-ID: From: Randy Bush To: David Mandelberg In-Reply-To: References: 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@ietf.org Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 00:20:29 -0000 good catch. one consequence an intermediate AS, which does not validate but signs, could apply prefix-based local policy based on the wrong prefix. same for any bgp4 peers it may have. randy From nobody Wed Aug 26 19:49:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762DB1B38FA for ; Wed, 26 Aug 2015 19:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 o3-_HQAeASwU for ; Wed, 26 Aug 2015 19:49:47 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D441B38F9 for ; Wed, 26 Aug 2015 19:49:47 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 20C033980B for ; Thu, 27 Aug 2015 02:49:47 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id B46A51ABFFC4 for ; Wed, 26 Aug 2015 22:49:45 -0400 (EDT) Date: Wed, 26 Aug 2015 22:49:45 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: 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: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 02:49:49 -0000 At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote: ... > I think this problem might be fixed if we modify the protocol to sign > all of the preceding signed data (rather than just the immediate, > previous signature). Agreed, assuming this means adding the (theoretically invariant) fields from the data to be signed in section 4.1 to the data to be signed in section 4.2. Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's AS Number" in section 4.2, this leaves the algorithm suite identifier, the AFI, the SAFI, and the NLRI to be added to the data to be signed in section 4.2. I doubt that there's any practical attack based on fiddling with the algorithm suite identifier (I'd expect any games there to cause validation failure, end of story), but maybe somebody has a more twisted imagination than mine, and, given that the algorithm suite ID is one byte long, I don't think it's worth trying to optimize that byte out of the section 4.2 signature. Presumably we want to keep the existing signature chaining, so I wouldn't remove anything from the data to be signed in section 4.2, just add the fields that are currently only present in section 4.1. David, if this is consistent with what you meant, cool, if not, say on. From nobody Thu Aug 27 05:12:29 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A3C1A8849 for ; Thu, 27 Aug 2015 05:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 H7JZcKW_D8xl for ; Thu, 27 Aug 2015 05:12:26 -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 3882C1A8A06 for ; Thu, 27 Aug 2015 05:12:24 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 71BB328B0041 for ; Thu, 27 Aug 2015 08:12:23 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 28B401F8035; Thu, 27 Aug 2015 08:12:23 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_57F4CAAE-D78A-4A97-8275-11CFEEFBE5EE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Sandra Murphy In-Reply-To: <836BAC24-6986-465B-BC32-A9AA78AF9A28@tislabs.com> Date: Thu, 27 Aug 2015 08:11:49 -0400 Message-Id: <4C5D2ECB-5BE9-4748-B779-2151815F14FE@tislabs.com> References: <836BAC24-6986-465B-BC32-A9AA78AF9A28@tislabs.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] IETF93 minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:12:28 -0000 --Apple-Mail=_57F4CAAE-D78A-4A97-8275-11CFEEFBE5EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking as one of the wg co-chairs: =46rom the minutes, here are a couple of action items: In the discussion of adverse-actions draft: =95 doug montgomery: in detection, worth = addressing pub point might offer different views to different = people/regions of the world. =95 steve: didn't address that. certainly is = possible if the primary detection is done by the INR themselves, = but they keep getting rosy view. INR might have options for = where to get resources. please send email to list so we = remember to talk about this =95 steve: rob, please send examples. what we = can do is give examples to make it clear that we did intend to = include this. =95 steve: rudiger: Did intend for this to be comprehensive. detection is going to be the same. = better job of explaining the implications of these things. = want to make reader understand this is a concern because of = this points. (=46rom the meetecho audio, these requests were a joint response to a = series of comments from Rob, Randy and Ruediger that are noted in the = minutes.) =95 sandy: recall happening two registries had = issued same resources to different people. how does that fit? =95 steve: send that to the list, need to think = about that In discussion of working group adoption: Sandy: ... =95 if authors want adoption, authors should = request it from the list In discussion of route leaks =95 sandy: found it listed as a tech report, can = be described as publicly available document. I have used the meetecho recordings to note the following possible = modifications to the minutes: At 1:57:42 (on the meetecho display), Randy says: I think I agree with Steve on the issue of hosted CAs. I=92m not sure that is the same as what the minutes say ("hosted CA" vs = "managed repository"): I agree with kent on managed repositories. [No, I did not review the entire audio, I just heard that in listening = for the following exchange.] The minutes say: =95 ??? (ripe): like idea, but where do you want = to go with this? =95 matthias: =95 (ripe): idea good, don't support a mandate = that all CAs must do this, but think it's good practice. idea = is good The recording does not show the people at mike, but from the audio I = think this is Kaveh Ranjbar. =97Sandy, speaking as one of the wg co-chairs --Apple-Mail=_57F4CAAE-D78A-4A97-8275-11CFEEFBE5EE 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 iQIcBAEBCgAGBQJV3v6LAAoJEHplpQeet0IZYawQAIwxiEYzxB3eh+yIh8FrFUDq tB0OyMVmQdY19Ed3HdpI/YbX7Zae2O28CPt/4g0lyPK4HQm3kl8mhIX9VD38Z2Hp ryHzysmSbebPbpX6DsbBPckD7Tj5ID9JSr0l8XDWVHsVvhT9Tx3VCdLPYef5NpnK +PtkwbRp1iaGjVMLH8DgnswmGi/MeaEainuJVB0p3mTgFt8koGunAberNamfYw5Y UPBzkWLTuwGTG4nZhOUYc0NulMRixcUndZIEif6OxyWoo7qNZQcQKxUkt6GjaM8x NGM8OYHFlu8HRuWp08M1z4ew9rHzEsDiEofNMFGE8Dr1Yz+3/mDLiLxzDJRM077T AaNdP+1dgP7p9wIqspY4laaDGq/5BaRwd1LM5oOrMfZgrFRPHxT8sW6eLf9FU0Xa SpiFeuJgsdXX1Tk1BMWpPraGk7/IhJzWXAFCyFIB0Q1L+upkbYRLMtioLKMJG1sA dKnHVSnHgiSN+pcECDbRidYBakwcPcTcWzZ+MBokYZRHak/3pM0LPCeLLhEbTlsm c6Sbc3VlL/npg2pJC0tcj10XJoNaOTUgvejuIBvX7gQpIb3S+YNj5JtaUXYnbBMl xmxHtKFsqAbFHK1yqDIYuBdTtrrNwnmq//6x67kBIc0K6XHmS19Jy0BXGvD3LapE 1VlJN441c/vKbMdAOQ1O =0pgf -----END PGP SIGNATURE----- --Apple-Mail=_57F4CAAE-D78A-4A97-8275-11CFEEFBE5EE-- From nobody Thu Aug 27 08:45:54 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469C71B2E01 for ; Thu, 27 Aug 2015 08:45:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 llT6nkjiAQ8q for ; Thu, 27 Aug 2015 08:45:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5E21B2DFC for ; Thu, 27 Aug 2015 08:45:50 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0794.namprd09.prod.outlook.com (10.163.43.144) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 27 Aug 2015 15:45:49 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0256.013; Thu, 27 Aug 2015 15:45:49 +0000 From: "Sriram, Kotikalapudi" To: David Mandelberg , "sidr@ietf.org" Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees Thread-Index: AQHQ4EXjUWOu4xHMLkqEedR7+Q4tdZ4f9sSQ Date: Thu, 27 Aug 2015 15:45:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.100] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0794; 5:6hvZN4410RsBDjRR8ZfJcz+JQ5D0kNo1rpsS5/h/+c0RT/Sl2kaGTWlT3nO2MyLmk6O4E/DoWRv3uo3+UNibs6Hh3RJdlWYWr+NLWFp/pkU8zJgUEo6B/f07oz8jfDE+OfYUvYOBV69//Aw96F6dMA==; 24:2x9y/teem3GtT0RDvogwQ9vo3pUaMdOPG1oSoY42cve9UZnxY3q4ucTUqS7nlcuz5jSLLahRIWWTGDU/Eu1rhNWjWZDd2Jx+6yP+S6MN0pE=; 20:zdEcYMpTiJ0Wwm81D9E+cbzHu+K0ZWxsl/HRBubz2L5HcG55YLJIaP58jDSe+0ZJkdAv1artkQ/Mn0iIEdqzWg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0794; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CY1PR09MB0794; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0794; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(76104003)(46102003)(54356999)(99286002)(77156002)(62966003)(2900100001)(2950100001)(68736005)(101416001)(50986999)(5007970100001)(5004730100002)(122556002)(106356001)(76176999)(64706001)(66066001)(5003600100002)(40100003)(76576001)(5001920100001)(5002640100001)(5001770100001)(77096005)(10400500002)(5001830100001)(189998001)(2656002)(230783001)(97736004)(5001860100001)(4001540100001)(105586002)(86362001)(2501003)(87936001)(107886002)(102836002)(106116001)(92566002)(33656002)(74316001)(5001960100002)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0794; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 15:45:49.2680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0794 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 15:45:53 -0000 >It appears that this guarantee will not always hold. Specifically, if >two non-adjacent ASes conspire, and they are separated by a sequence of >ASes that sign path data that they have not verified, then the >conspiring ASes can violate the guarantee.=20 Agree with that.=20 What do you think of the following two-update collusion scenario? -- > A --> B --> C --> D --> E A and D are colluding. B and C are signing without verifying. First update at time=3D t0: A signs and forwards an update normally (without any corruption).=20 The update propagates via B and C to D. D receives it and stores it, but does not forward to E (or anyone). Second update at time=3D t1 (=3D t0 + delta): A sends an intentionally corrupted version of the update (signed), while keeping the same NLRI as before.=20 B and C are still signing but not verifying. The update propagates via B and C to D. Now D replaces=20 this corrupted update with the earlier clean one (received at t0),=20 and propagates to E. The resulting update from D to E is valid. One can argue that there is violation of the guarantee (in Section 7.1) at time t1. The valid route propagated from D to E does not agree with the route that B or C forwarded (at time t1) for the NLRI in consideration. >I think this problem might be fixed if we modify the protocol to sign >all of the preceding signed data (rather than just the immediate, >previous signature). If we agree that the above two-update collusion scenario=20 is something we care about, then it should be noted that this fix does not prevent it. Sriram From nobody Thu Aug 27 10:58:30 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E951B301B for ; Thu, 27 Aug 2015 10:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 g3OHtQ6jix9Z for ; Thu, 27 Aug 2015 10:58:28 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0CB1A89C5 for ; Thu, 27 Aug 2015 10:58:28 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 241AB39848 for ; Thu, 27 Aug 2015 17:58:28 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id A35401AC51E2 for ; Thu, 27 Aug 2015 13:58:26 -0400 (EDT) Date: Thu, 27 Aug 2015 13:58:26 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: 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: <20150827175826.A35401AC51E2@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:58:29 -0000 At Thu, 27 Aug 2015 15:45:49 +0000, Sriram, Kotikalapudi wrote: > > What do you think of the following two-update collusion scenario? > -- > A --> B --> C --> D --> E > A and D are colluding. B and C are signing without verifying. > First update at time= t0: > A signs and forwards an update normally (without any corruption). > The update propagates via B and C to D. > D receives it and stores it, but does not forward to E (or anyone). > Second update at time= t1 (= t0 + delta): > A sends an intentionally corrupted version of the update (signed), > while keeping the same NLRI as before. > B and C are still signing but not verifying. > The update propagates via B and C to D. Now D replaces > this corrupted update with the earlier clean one (received at t0), > and propagates to E. The resulting update from D to E is valid. > One can argue that there is violation of the guarantee (in Section 7.1) > at time t1. The valid route propagated from D to E does not > agree with the route that B or C forwarded (at time t1) > for the NLRI in consideration. If I understand your scenario correctly, as far as folks further along the path are concerned, this is a replay attack by D. That D is doing this to cover up something bad that A is doing to B and C is almost irrelevant, as is the specific nature of whatever bad thing A is doing to B and C. So, yeah, OK, it's a form of collusion, but it's not one that relies on a weakness in the signature semantics, it's one that relies on lack of protection against replay attacks, something the WG discussed and rejected. Can't speak for anybody else, but I'm not particularly interested in exhuming the replay horse at this late date. From nobody Thu Aug 27 12:15:59 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B361B3B67 for ; Thu, 27 Aug 2015 12:15:58 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KkTVYyKpeVwD for ; Thu, 27 Aug 2015 12:15:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F821B3B50 for ; Thu, 27 Aug 2015 12:15:55 -0700 (PDT) Received: from BN3PR09MB0355.namprd09.prod.outlook.com (10.160.115.152) by BN3PR09MB0356.namprd09.prod.outlook.com (10.160.115.153) with Microsoft SMTP Server (TLS) id 15.1.243.23; Thu, 27 Aug 2015 19:15:52 +0000 Received: from BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) by BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) with mapi id 15.01.0243.020; Thu, 27 Aug 2015 19:15:52 +0000 From: "Borchert, Oliver" To: "sidr@ietf.org" Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees Thread-Index: AQHQ4EXk8vgV73xBckONsKYcP4tTrp4f/liAgAAlDQD//9KSAA== Date: Thu, 27 Aug 2015 19:15:52 +0000 Message-ID: References: <20150827175826.A35401AC51E2@minas-ithil.hactrn.net> In-Reply-To: <20150827175826.A35401AC51E2@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.5.4.150722 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-microsoft-exchange-diagnostics: 1; BN3PR09MB0356; 5:7jatvv9pKI6ozuRt9lwdue+m3PLUz9IWSAxB9dyeeKmkfiQD2NI9KuAt8py0Bai6AyvtCZQ2UM8ghFDIoapea8g3d+2RJPROwfopq4KE7X7hCoZhhirX9MzhGmsBktddBO5v4VzcenNHDBnCiHVd0w==; 24:dzfyzvQAIDerHt7voZKoFDhL0sCo8eKSNyx0WAhTuvIbkzndm89YK58tMNgvawq21lnDCLvsns3h0dlfRwDnrBG0liN/9SWMl0m3tT+Gqrw=; 20:+R4MPAB1lBgIJRWPPDEB00W/vZp+aOuppJc7KjXYhVJjx4AosL+42dy64BQ/DqlBnVoBebKB8cpEz7OZbDIn8Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR09MB0356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN3PR09MB0356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR09MB0356; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(76104003)(377454003)(189002)(199003)(479174004)(101416001)(50986999)(122556002)(76176999)(2351001)(36756003)(2501003)(97736004)(106116001)(230783001)(66066001)(83506001)(64706001)(5001830100001)(99286002)(4001350100001)(189998001)(110136002)(5001860100001)(107886002)(4001540100001)(105586002)(40100003)(54356999)(5007970100001)(5004730100002)(81156007)(2656002)(86362001)(5001960100002)(450100001)(15975445007)(2900100001)(77096005)(5002640100001)(92566002)(87936001)(68736005)(102836002)(77156002)(62966003)(19580395003)(106356001)(10400500002)(19580405001)(2950100001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR09MB0356; H:BN3PR09MB0355.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <34FB4169029DF147B5257DE2603BE7BD@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 19:15:52.7722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR09MB0356 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:15:58 -0000 If I understand David=B9s attack vector correct than the attack would look as follows: For the path =8B > A =8B> B =8B> C =8B> D =8B> E with A and D conspiring an= d B and C only signing but not validating: A signs the path to D and not to B but sends it to B. Because B and C don=B9t validate, just sign they forward the path to D. D removed B and C from the path and forwards the path as =8B> A =8B> D to = E. Now E verifies the path as valid and moves on. If this is what David had in mind then I agree that the security guarantee in 7.1 does not hold up. Oliver On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein" wrote: >At Thu, 27 Aug 2015 15:45:49 +0000, Sriram, Kotikalapudi wrote: >>=20 >> What do you think of the following two-update collusion scenario? >> -- > A --> B --> C --> D --> E >> A and D are colluding. B and C are signing without verifying. >> First update at time=3D t0: >> A signs and forwards an update normally (without any corruption). >> The update propagates via B and C to D. >> D receives it and stores it, but does not forward to E (or anyone). >> Second update at time=3D t1 (=3D t0 + delta): >> A sends an intentionally corrupted version of the update (signed), >> while keeping the same NLRI as before. >> B and C are still signing but not verifying. >> The update propagates via B and C to D. Now D replaces >> this corrupted update with the earlier clean one (received at t0), >> and propagates to E. The resulting update from D to E is valid. >> One can argue that there is violation of the guarantee (in Section 7.1) >> at time t1. The valid route propagated from D to E does not >> agree with the route that B or C forwarded (at time t1) >> for the NLRI in consideration. > >If I understand your scenario correctly, as far as folks further along >the path are concerned, this is a replay attack by D. That D is doing >this to cover up something bad that A is doing to B and C is almost >irrelevant, as is the specific nature of whatever bad thing A is doing >to B and C. > >So, yeah, OK, it's a form of collusion, but it's not one that relies >on a weakness in the signature semantics, it's one that relies on lack >of protection against replay attacks, something the WG discussed and >rejected. Can't speak for anybody else, but I'm not particularly >interested in exhuming the replay horse at this late date. > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Aug 27 12:23:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652411ACEBE for ; Thu, 27 Aug 2015 12:23:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nssBzApgCkZF for ; Thu, 27 Aug 2015 12:23:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324371AD0C0 for ; Thu, 27 Aug 2015 12:23:47 -0700 (PDT) Received: from BN3PR09MB0355.namprd09.prod.outlook.com (10.160.115.152) by BN3PR09MB0356.namprd09.prod.outlook.com (10.160.115.153) with Microsoft SMTP Server (TLS) id 15.1.243.23; Thu, 27 Aug 2015 19:23:45 +0000 Received: from BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) by BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) with mapi id 15.01.0243.020; Thu, 27 Aug 2015 19:23:45 +0000 From: "Borchert, Oliver" To: "sidr@ietf.org" Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees Thread-Index: AQHQ4EXk8vgV73xBckONsKYcP4tTrp4f/liAgAAlDQD//9KSAIAAAjMA Date: Thu, 27 Aug 2015 19:23:45 +0000 Message-ID: References: <20150827175826.A35401AC51E2@minas-ithil.hactrn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-microsoft-exchange-diagnostics: 1; BN3PR09MB0356; 5:P8cu+5npLS9VouDzyftofC14XrP22kepPOozqJu/efIhIcostidrMtK3VxL516aqOrjhrsabMXKgrrtZUr77Xqu4aHxEzUL669OrBsOuxi9JmHzNtgidkxIAqFbA1vpUvBuExtFvUjiHvH5PSY/CEw==; 24:joU9bUXrQ5RViXR83Gv8nYBYDlmPoTlosqHmsAXAvBNQTkaHrZkObPH8h3i6uLoXRE/ljFWJuHwu+sSyP1l7vVLBZ8HygNdoy3mEBxaFs2M=; 20:wLNFAnErBdDhFFg3KZOtqPt4dHmwBPrz4wv8whO1b/VBPOHPu5gh6JtQwlkFCfMPZtJKR1cCVdxXoMSCEuZ7kg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR09MB0356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BN3PR09MB0356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR09MB0356; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(189002)(199003)(377454003)(76104003)(24454002)(2900100001)(77096005)(5001960100002)(86362001)(2656002)(15975445007)(450100001)(19580395003)(62966003)(106356001)(2950100001)(46102003)(10400500002)(19580405001)(68736005)(87936001)(102836002)(92566002)(5002640100001)(77156002)(230783001)(66066001)(83506001)(2501003)(106116001)(97736004)(64706001)(122556002)(76176999)(2351001)(50986999)(101416001)(36756003)(105586002)(40100003)(54356999)(4001540100001)(5001920100001)(5004730100002)(81156007)(5007970100001)(93886004)(4001350100001)(99286002)(5001830100001)(107886002)(189998001)(110136002)(5001860100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR09MB0356; H:BN3PR09MB0355.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 19:23:45.4761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR09MB0356 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:23:49 -0000 SSBub3RpY2VkIE91dGxvb2sgY2hhbmdlZCBzb21lIGNoYXJhY3RlcnMgc28gaGVyZSBhZ2FpbjoN Cg0KDQpJZiBJIHVuZGVyc3RhbmQgRGF2aWRzIGF0dGFjayB2ZWN0b3IgY29ycmVjdCB0aGFuIHRo ZSBhdHRhY2sgd291bGQgbG9vaw0KYXMgZm9sbG93czoNCg0KRm9yIHRoZSBwYXRoIC0+IEEgLT4g QiAtPiBDIC0+IEQgLT4gRSB3aXRoIEEgYW5kIEQgY29uc3BpcmluZyBhbmQgQiBhbmQgQw0Kb25s eSBzaWduaW5nIGJ1dCBub3QgdmFsaWRhdGluZzoNCg0KQSBzaWducyB0aGUgcGF0aCB0byBEIGFu ZCBub3QgdG8gQiBidXQgc2VuZHMgaXQgdG8gQi4gQmVjYXVzZSBCIGFuZCBDDQpkbyBub3QgdmFs aWRhdGUsIGp1c3Qgc2lnbiB0aGV5IGZvcndhcmQgdGhlIHBhdGggdG8gRC4NCkQgcmVtb3ZlZCBC IGFuZCBDIGZyb20gdGhlIHBhdGggYW5kIGZvcndhcmRzIHRoZSBwYXRoIGFzIC0+IEEgLT4gRCAg dG8gRS4NCk5vdyBFIHZlcmlmaWVzIHRoZSBwYXRoIGFzIHZhbGlkIGFuZCBtb3ZlcyBvbi4NCg0K SWYgdGhpcyBpcyB3aGF0IERhdmlkIGhhZCBpbiBtaW5kIHRoZW4gSSBhZ3JlZSB0aGF0IHRoZSBz ZWN1cml0eSBndWFyYW50ZWUNCmluIDcuMSBkb2VzIG5vdCBob2xkIHVwLg0KDQoNCk9saXZlcg0K DQoNCg0KDQoNCk9uIDgvMjcvMTUsIDM6MTUgUE0sICJzaWRyIG9uIGJlaGFsZiBvZiBCb3JjaGVy dCwgT2xpdmVyIg0KPHNpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygb2xpdmVyLmJv cmNoZXJ0QG5pc3QuZ292PiB3cm90ZToNCg0KPklmIEkgdW5kZXJzdGFuZCBEYXZpZMK5cyBhdHRh Y2sgdmVjdG9yIGNvcnJlY3QgdGhhbiB0aGUgYXR0YWNrIHdvdWxkIGxvb2sNCj5hcyBmb2xsb3dz Og0KPg0KPkZvciB0aGUgcGF0aCDigLkgPiBBIOKAuT4gQiDigLk+IEMg4oC5PiBEIOKAuT4gRSB3 aXRoIEEgYW5kIEQgY29uc3BpcmluZyBhbmQgQiBhbmQgQw0KPm9ubHkgc2lnbmluZyBidXQgbm90 IHZhbGlkYXRpbmc6DQo+DQo+QSBzaWducyB0aGUgcGF0aCB0byBEIGFuZCBub3QgdG8gQiBidXQg c2VuZHMgaXQgdG8gQi4gQmVjYXVzZSBCIGFuZCBDDQo+ZG9uwrl0IHZhbGlkYXRlLCBqdXN0IHNp Z24gdGhleSBmb3J3YXJkIHRoZSBwYXRoIHRvIEQuDQo+RCByZW1vdmVkIEIgYW5kIEMgZnJvbSB0 aGUgcGF0aCBhbmQgZm9yd2FyZHMgdGhlIHBhdGggYXMg4oC5PiBBIOKAuT4gRCAgdG8gRS4NCj5O b3cgRSB2ZXJpZmllcyB0aGUgcGF0aCBhcyB2YWxpZCBhbmQgbW92ZXMgb24uDQo+DQo+SWYgdGhp cyBpcyB3aGF0IERhdmlkIGhhZCBpbiBtaW5kIHRoZW4gSSBhZ3JlZSB0aGF0IHRoZSBzZWN1cml0 eSBndWFyYW50ZWUNCj5pbiA3LjEgZG9lcyBub3QgaG9sZCB1cC4NCj4NCj4NCj5PbGl2ZXINCj4N Cj4NCj4NCj5PbiA4LzI3LzE1LCAxOjU4IFBNLCAic2lkciBvbiBiZWhhbGYgb2YgUm9iIEF1c3Rl aW4iDQo+PHNpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc3JhQGhhY3Rybi5uZXQ+ IHdyb3RlOg0KPg0KPj5BdCBUaHUsIDI3IEF1ZyAyMDE1IDE1OjQ1OjQ5ICswMDAwLCBTcmlyYW0s IEtvdGlrYWxhcHVkaSB3cm90ZToNCj4+PiANCj4+PiBXaGF0IGRvIHlvdSB0aGluayBvZiB0aGUg Zm9sbG93aW5nIHR3by11cGRhdGUgY29sbHVzaW9uIHNjZW5hcmlvPw0KPj4+IC0tID4gQSAtLT4g QiAtLT4gQyAtLT4gRCAtLT4gRQ0KPj4+IEEgYW5kIEQgYXJlIGNvbGx1ZGluZy4gQiBhbmQgQyBh cmUgc2lnbmluZyB3aXRob3V0IHZlcmlmeWluZy4NCj4+PiBGaXJzdCB1cGRhdGUgYXQgdGltZT0g dDA6DQo+Pj4gQSBzaWducyBhbmQgZm9yd2FyZHMgYW4gdXBkYXRlIG5vcm1hbGx5ICh3aXRob3V0 IGFueSBjb3JydXB0aW9uKS4NCj4+PiBUaGUgdXBkYXRlIHByb3BhZ2F0ZXMgdmlhIEIgYW5kIEMg dG8gRC4NCj4+PiBEIHJlY2VpdmVzIGl0IGFuZCBzdG9yZXMgaXQsIGJ1dCBkb2VzIG5vdCBmb3J3 YXJkIHRvIEUgKG9yIGFueW9uZSkuDQo+Pj4gU2Vjb25kIHVwZGF0ZSBhdCB0aW1lPSB0MSAoPSB0 MCArIGRlbHRhKToNCj4+PiBBIHNlbmRzIGFuIGludGVudGlvbmFsbHkgY29ycnVwdGVkIHZlcnNp b24gb2YgdGhlIHVwZGF0ZSAoc2lnbmVkKSwNCj4+PiB3aGlsZSBrZWVwaW5nIHRoZSBzYW1lIE5M UkkgYXMgYmVmb3JlLg0KPj4+IEIgYW5kIEMgYXJlIHN0aWxsIHNpZ25pbmcgYnV0IG5vdCB2ZXJp ZnlpbmcuDQo+Pj4gVGhlIHVwZGF0ZSBwcm9wYWdhdGVzIHZpYSBCIGFuZCBDIHRvIEQuIE5vdyBE IHJlcGxhY2VzDQo+Pj4gdGhpcyBjb3JydXB0ZWQgdXBkYXRlIHdpdGggdGhlIGVhcmxpZXIgY2xl YW4gb25lIChyZWNlaXZlZCBhdCB0MCksDQo+Pj4gYW5kIHByb3BhZ2F0ZXMgdG8gRS4gVGhlIHJl c3VsdGluZyB1cGRhdGUgZnJvbSBEIHRvIEUgaXMgdmFsaWQuDQo+Pj4gT25lIGNhbiBhcmd1ZSB0 aGF0IHRoZXJlIGlzIHZpb2xhdGlvbiBvZiB0aGUgZ3VhcmFudGVlIChpbiBTZWN0aW9uIDcuMSkN Cj4+PiBhdCB0aW1lIHQxLiBUaGUgdmFsaWQgcm91dGUgcHJvcGFnYXRlZCBmcm9tIEQgdG8gRSBk b2VzIG5vdA0KPj4+IGFncmVlIHdpdGggdGhlIHJvdXRlIHRoYXQgQiBvciBDIGZvcndhcmRlZCAo YXQgdGltZSB0MSkNCj4+PiBmb3IgdGhlIE5MUkkgaW4gY29uc2lkZXJhdGlvbi4NCj4+DQo+Pklm IEkgdW5kZXJzdGFuZCB5b3VyIHNjZW5hcmlvIGNvcnJlY3RseSwgYXMgZmFyIGFzIGZvbGtzIGZ1 cnRoZXIgYWxvbmcNCj4+dGhlIHBhdGggYXJlIGNvbmNlcm5lZCwgdGhpcyBpcyBhIHJlcGxheSBh dHRhY2sgYnkgRC4gIFRoYXQgRCBpcyBkb2luZw0KPj50aGlzIHRvIGNvdmVyIHVwIHNvbWV0aGlu ZyBiYWQgdGhhdCBBIGlzIGRvaW5nIHRvIEIgYW5kIEMgaXMgYWxtb3N0DQo+PmlycmVsZXZhbnQs IGFzIGlzIHRoZSBzcGVjaWZpYyBuYXR1cmUgb2Ygd2hhdGV2ZXIgYmFkIHRoaW5nIEEgaXMgZG9p bmcNCj4+dG8gQiBhbmQgQy4NCj4+DQo+PlNvLCB5ZWFoLCBPSywgaXQncyBhIGZvcm0gb2YgY29s bHVzaW9uLCBidXQgaXQncyBub3Qgb25lIHRoYXQgcmVsaWVzDQo+Pm9uIGEgd2Vha25lc3MgaW4g dGhlIHNpZ25hdHVyZSBzZW1hbnRpY3MsIGl0J3Mgb25lIHRoYXQgcmVsaWVzIG9uIGxhY2sNCj4+ b2YgcHJvdGVjdGlvbiBhZ2FpbnN0IHJlcGxheSBhdHRhY2tzLCBzb21ldGhpbmcgdGhlIFdHIGRp c2N1c3NlZCBhbmQNCj4+cmVqZWN0ZWQuICBDYW4ndCBzcGVhayBmb3IgYW55Ym9keSBlbHNlLCBi dXQgSSdtIG5vdCBwYXJ0aWN1bGFybHkNCj4+aW50ZXJlc3RlZCBpbiBleGh1bWluZyB0aGUgcmVw bGF5IGhvcnNlIGF0IHRoaXMgbGF0ZSBkYXRlLg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+c2lkciBtYWlsaW5nIGxpc3QNCj4+c2lkckBp ZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNpZHIg bWFpbGluZyBsaXN0DQo+c2lkckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lkcg0KDQo= From nobody Thu Aug 27 13:45:29 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E031A903E for ; Thu, 27 Aug 2015 13:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Y3LEOgkUc_9n for ; Thu, 27 Aug 2015 13:45:26 -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 E719E1A8BBD for ; Thu, 27 Aug 2015 13:45:25 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4BB0F28B003D; Thu, 27 Aug 2015 16:45:25 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 4216A1F804E; Thu, 27 Aug 2015 16:45:25 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7D8E9C43-EE12-4E73-860A-3D340BF2E65E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Sandra Murphy In-Reply-To: Date: Thu, 27 Aug 2015 16:45:11 -0400 Message-Id: <25C98F11-9273-4B80-8B3A-FB486166E21D@tislabs.com> References: To: Randy Bush X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr@ietf.org, David Mandelberg , Sandra Murphy Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:45:27 -0000 --Apple-Mail=_7D8E9C43-EE12-4E73-860A-3D340BF2E65E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking as regular ol=92 member: On Aug 26, 2015, at 8:20 PM, Randy Bush wrote: > good catch. >=20 > one consequence >=20 > an intermediate AS, which does not validate but signs, could apply I=92d say that the intermediate AS who didn=92t verify the signatures it = received could be acting on bad info at any time, without any conspiring = ASs around. The intermediate AS has no more assurance than a non-bgpsec = speaker that the route it receives is valid. So I don=92t think anything that happens to the intermediate AS is = something to worry about. > prefix-based local policy based on the wrong prefix. same for any > bgp4 peers it may have. I see nothing in David=92s message about a prefix, so I=92m not sure = what you are talking about. But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) peers = have chosen to be insecure - I see no reason to be concerned. =97Sandy, speaking as regular ol=92 member --Apple-Mail=_7D8E9C43-EE12-4E73-860A-3D340BF2E65E 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 iQIcBAEBCgAGBQJV33bfAAoJEHplpQeet0IZDOMQAKQZI/k1Wh5JzTilXuVR8mOl ayfxyHPXPp+9DafR4PyyMY5KGNLXueSWbwWB5rx/1+z9/ovZkNu6C+VNNt0uQypb YlZ0fPQuvf0xlFAu4pPZ+4G5YjJFhEfEuM33INJsnbcS+EUuqgbqzTWNT60K1OQf bSnkWuoW4Mdgv5oRWvOshvk9P1MlymzgaPoL6uulfrrWEoKin3SFFxfeZGQJ5jI8 aE03eOoo6Deq/G+o388B9fnMI2BFKXYvE+yJ8Nu67ZjOjBU20oPeydo6dwnplUHm v2lhsYWb5Vw4fV/HQsOQUdjzTUMl+zQ9qsiEo8WhSoZvGV1KOeNjYFQgjG8MbpKY u4GO+UkkSC8vl+CPN7o7YpG3QIdjkVNca8Pcp9R2cqLFNfUgquwlZ1AcPjwY3jZt r8Yo4lIo/SLy2NVktaX0qDOLyPn3M0mYoHo3CaZuLeUXW/n+lwNAys/zv/f7Ufxl P7N10uuvoOdhd0wDHAwikr/03D5nftLkANXlx/QpwCAqlO+ywAVC293zW3WBVxQ3 u+nECAXNpfm39nzE7RWyXLTj+nyWjr2Z8Zib/l2WASVDq95hUY/8TKHCNu3eiQ4a ++4p1qoxgsY+XM04JWQ7ZY99aBFO7hKWAk3FlL6hyq+ArwEyIgyq3s6z3Um/SJPs B1ePUQ6O52QPvkXu6DxA =LOx2 -----END PGP SIGNATURE----- --Apple-Mail=_7D8E9C43-EE12-4E73-860A-3D340BF2E65E-- From nobody Thu Aug 27 14:02:41 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63B41A92E6 for ; Thu, 27 Aug 2015 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bcnlcnw7WdS8 for ; Thu, 27 Aug 2015 14:02:38 -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 62E8A1A8AB5 for ; Thu, 27 Aug 2015 14:02:30 -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 1ZV4JY-00046I-HS; Thu, 27 Aug 2015 21:02:28 +0000 Date: Fri, 28 Aug 2015 06:02:27 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <25C98F11-9273-4B80-8B3A-FB486166E21D@tislabs.com> References: <25C98F11-9273-4B80-8B3A-FB486166E21D@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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 21:02:40 -0000 >> an intermediate AS, which does not validate but signs, could apply=20 > I=E2=80=99d say that the intermediate AS who didn=E2=80=99t verify the si= gnatures it > received could be acting on bad info at any time, without any > conspiring ASs around. The intermediate AS has no more assurance than > a non-bgpsec speaker that the route it receives is valid. it is not worse than unsecured is a form of reasoning i do not buy. >> prefix-based local policy based on the wrong prefix. same for any >> bgp4 peers it may have. >=20 > I see nothing in David=E2=80=99s message about a prefix, so I=E2=80=99m n= ot sure what > you are talking about. sorry, i forgot that bgp announces beers. the colluding systems could have signed a hash of lager when the label on the announcement was pils. the intermediate system which does not validate could base it's mains order on pils and tell it's non-validating peers to have a pils with them. > But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) peers > have chosen to be insecure - I see no reason to be concerned. same fallacious argument. we are supposed to be making things better, not leaving them the same. randy From nobody Thu Aug 27 16:34:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049781B2C75 for ; Thu, 27 Aug 2015 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jl2J2gVLHKM6 for ; Thu, 27 Aug 2015 16:33:57 -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 AFE041A90E9 for ; Thu, 27 Aug 2015 16:33:56 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 27CD028B0041; Thu, 27 Aug 2015 19:33:56 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1F57A1F8035; Thu, 27 Aug 2015 19:33:56 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E17CB168-02CE-4BA2-A54A-92791B7BB67E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Sandra Murphy In-Reply-To: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> Date: Thu, 27 Aug 2015 19:33:14 -0400 Message-Id: <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> References: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: [sidr] WG adoption call for draft-dseomn-sidr-slurm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 23:33:59 -0000 --Apple-Mail=_E17CB168-02CE-4BA2-A54A-92791B7BB67E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors of draft-dseomn-sidr-slurm adoption have requested working = group adoption. A working group adoption call starts now and will end 14 days from now = on 10 September. 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. --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_E17CB168-02CE-4BA2-A54A-92791B7BB67E 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 iQIcBAEBCgAGBQJV355PAAoJEHplpQeet0IZBMwP/i3XRAtlRTHEifvn+8v9h30o iKjEXvPZGPVMVmHIs6e/LAfPi7Iz8YaVit6zos3O/84CITLGNta4sW02THFnOEbz Rd2nsTFHMlsYNFTqZjhrKgJwheI1S/xogLY6ui/HWz6MBrFjwreLm0nRs3W7x34r oXetxv2KHH4FsdywGyV79MVnZhkfO+TEDs1vdVwh0mm3u3dvIxFgo1bi3mYLcMfE PiN5HQ/5cn/xdkbpNzxnvRGU3R8P8ddhIyuVJM9g/isJZYJWsX53JJBQMXASWgrD W813fbXrAwjsMf6+6s3zsecx4H2doYKFq0gOWCd5qSBgahQfO9qNlJi8iRmZC5iB /yxNlQcl8LKed7VJWyiF/Nw5dQ4Ind568EnslmHD2cf82rvFQZ9nE8PWkQ/lzOPi CKb8GsGC8qAwIzmBRM2F1BgMsxY75IZeyi3txC8Q9lyAZARfJziFeT004zI28GKQ TR9nM+RDDoN7WTFt3gupl/R8g/cjKgYVJQJGTXM9f/Ato1zwfkxWElDdY37Doh3v 8g+MAa604dGBHHRPbubH3go8SZIFpiLc40iDIX+s6WRMlgBhz9DmM/wWtzQVyzAU xCzNtfq1PK3kk8BiAZRJDRo+J+u0qVrdVUMlx2xDnAWXop2Xw9djZ5DXK3wPePS0 n9LvFi2cCKbV/ttjoM2e =tUXV -----END PGP SIGNATURE----- --Apple-Mail=_E17CB168-02CE-4BA2-A54A-92791B7BB67E-- From nobody Fri Aug 28 05:48:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429A41AC3B6 for ; Fri, 28 Aug 2015 05:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DMYRv712TR37 for ; Fri, 28 Aug 2015 05:48:17 -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 97BEE1A89F6 for ; Fri, 28 Aug 2015 05:48:17 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50044 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZVJ4l-000MRU-6G for sidr@ietf.org; Fri, 28 Aug 2015 08:48:11 -0400 To: sidr@ietf.org References: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> From: Stephen Kent Message-ID: <55E05889.1000706@bbn.com> Date: Fri, 28 Aug 2015 08:48:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> Content-Type: multipart/alternative; boundary="------------090806030703020405030301" Archived-At: Subject: Re: [sidr] WG adoption call for draft-dseomn-sidr-slurm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:48:19 -0000 This is a multi-part message in MIME format. --------------090806030703020405030301 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Not surprisingly, I support adoption and will participate in the discussion. Steve > The authors of draft-dseomn-sidr-slurm adoption have requested working group adoption. > > A working group adoption call starts now and will end 14 days from now on 10 September. > > 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. > > --Sandy, speaking as one of the wg co-chairs > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------090806030703020405030301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Not surprisingly, I support adoption and will participate in the discussion.

Steve
The authors of draft-dseomn-sidr-slurm adoption have requested working group adoption.

A working group adoption call starts now and will end 14 days from now on 10 September.

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.

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




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

--------------090806030703020405030301-- From nobody Fri Aug 28 08:46:35 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49C31B2A88 for ; Fri, 28 Aug 2015 08:46:33 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6k4KEi1CVfyM for ; Fri, 28 Aug 2015 08:46:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9351B2A51 for ; Fri, 28 Aug 2015 08:46:31 -0700 (PDT) Received: from BN3PR09MB0355.namprd09.prod.outlook.com (10.160.115.152) by BN3PR09MB0355.namprd09.prod.outlook.com (10.160.115.152) with Microsoft SMTP Server (TLS) id 15.1.243.23; Fri, 28 Aug 2015 15:46:29 +0000 Received: from BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) by BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) with mapi id 15.01.0243.020; Fri, 28 Aug 2015 15:46:29 +0000 From: "Borchert, Oliver" To: Sandra Murphy , David Mandelberg Thread-Topic: [sidr] WG adoption call for draft-dseomn-sidr-slurm Thread-Index: AQHQ4SDeORiK8VBPE0+f3iqgX7I86p4hTBSA Date: Fri, 28 Aug 2015 15:46:28 +0000 Message-ID: References: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> In-Reply-To: <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-microsoft-exchange-diagnostics: 1; BN3PR09MB0355; 5:aFEQH+L3SZXOHIm0N068iIf88BeYgbhImH2zaip0iwjBg4qWV2XJpQJ8uIp0IBE7Z8ikxCP/4nq8Nf+92PkX5rbScNBoTTtkt8ky31a2LIJXB6rNGQuXyRiElnYqcArX2Px9p1ulF5jCHNixCq2KiA==; 24:od0IHL3MWZt6GhPBOb4A0OLxFmyMgpnYe4nujoH6NyEE2BF3N06yGwa0CNuAE1is4Ku2ZCTgxTU5uUY1qk8rNxWIzxAgNoxm9u20vJu3e4A=; 20:xMKqS2CYklBnzBHNu/ZcAMBXOEXWvfj4FWMFk3GQEigirErZk+pN3WUdgrNo03aHJGV/Gi23C+gadp1jj30vDg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR09MB0355; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN3PR09MB0355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR09MB0355; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(479174004)(377454003)(189002)(24454002)(19580395003)(4001540100001)(99286002)(54356999)(105586002)(81156007)(5001830100001)(97736004)(76176999)(46102003)(36756003)(106116001)(5001770100001)(4001350100001)(19580405001)(5001960100002)(50986999)(189998001)(101416001)(5007970100001)(230783001)(2950100001)(122556002)(102836002)(5002640100001)(2656002)(77096005)(5001860100001)(10400500002)(40100003)(86362001)(87936001)(68736005)(62966003)(77156002)(106356001)(92566002)(83506001)(5004730100002)(66066001)(2900100001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR09MB0355; H:BN3PR09MB0355.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <4F35BD591A488441872AAE244B5FB116@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2015 15:46:28.7604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR09MB0355 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-dseomn-sidr-slurm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:46:33 -0000 I support adoption and will participate in the discussion. Oliver On 8/27/15, 7:33 PM, "sidr on behalf of Sandra Murphy" wrote: >The authors of draft-dseomn-sidr-slurm adoption have requested working >group adoption. > >A working group adoption call starts now and will end 14 days from now on >10 September. > >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. > >--Sandy, speaking as one of the wg co-chairs > From nobody Fri Aug 28 14:45:23 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411C21B3082 for ; Fri, 28 Aug 2015 14:45:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HF6KpPydmEvM for ; Fri, 28 Aug 2015 14:45:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024D21B307F for ; Fri, 28 Aug 2015 14:45:18 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0890.namprd09.prod.outlook.com (10.163.43.28) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 28 Aug 2015 21:45:18 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 28 Aug 2015 21:45:17 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0256.013; Fri, 28 Aug 2015 21:45:17 +0000 From: "Sriram, Kotikalapudi" To: Rob Austein , "sidr@ietf.org" Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees Thread-Index: AQHQ4EXjUWOu4xHMLkqEedR7+Q4tdZ4f9sSQgAAsoQCAAcX5oA== Date: Fri, 28 Aug 2015 21:45:17 +0000 Message-ID: References: <20150827175826.A35401AC51E2@minas-ithil.hactrn.net> In-Reply-To: <20150827175826.A35401AC51E2@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; hactrn.net; dkim=none (message not signed) header.d=none;hactrn.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.140.100] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0793; 5:q9JDsO2OQl2cvoEJJd6LrFjO8pHlA28BKdPDMIAHL0L7BBN4tNboTgZ1wV+D68pDxHql2psiY+iykrW5fPDuVYqSM93f40v+SAlzTHFAq/sg8te9oYD/vUOa6A1cRsK1fF+On0P12UfKfx9hrnkPig==; 24:iV0AI/rlchwogm1bLuRkWlws+8TjA3vt1cfRaxAdt+7/PN4HFvF0vy/dF217gQRv8BrTWIAe0wYOpgT33c6Zs1C16mET/eiOgkisKWVBC0g=; 20:7mY95b4HylVf0MMFvMRdhlSeSFtpJihzu40S7jQFH+Tjv2t9JebfcxVg+2HAiFDXkCSpCyJOi9zUvcT1c8s9eA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0890; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CY1PR09MB0793; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(107886002)(102836002)(97736004)(50986999)(62966003)(2501003)(76176999)(5001770100001)(77156002)(2900100001)(5002640100001)(15975445007)(74316001)(5001960100002)(189998001)(19580395003)(2950100001)(101416001)(92566002)(54356999)(87936001)(4001540100001)(106116001)(5001830100001)(5001860100001)(81156007)(2656002)(64706001)(46102003)(68736005)(122556002)(10400500002)(66066001)(77096005)(5007970100001)(86362001)(106356001)(40100003)(230783001)(5004730100002)(99286002)(76576001)(5003600100002)(33656002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0793; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2015 21:45:17.0375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0793 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0890; 2:iFpG45ClZynZFZBUDEp0mDMmKxKka2drwC1U7kS3tkqvDq8IeBCiXKcEbGAH8MlTh0l24X8wh8XxZHAMmvemKNtsQ0tUA3gCpMFc+qGvT/Cc2vXhLDhONGjIRlDgFeWsz2b99osPs20gLRvPq9s9UOf+7UZpJNleld1Pyu7ts5w=; 3:AOYMzbWoQRlw+9cCHsGiHQJ+H8zN/9cpk2uKnyZ2GwoteIdNRIVr8Jz1tSBqMhQ44wFhtL0HzmnBcBSK2yooolME5sX1aAALmWwXTmIhVpomCgsKPUPXyExXKhBA5uoBchM4VNyaV0MSw4yiVu/VKg==; 25:5ZEM59kP8A+J4Rl6UHHOaUoPTNQfsCRIIJDMH1YQf7DuEhIbuggmhHf6PhUUy+XCCm7kudF9bmBm5CRIAFzC9sFzlp2AJIdcpYEZEyzRdD6Z/0kp4dLIt6nkLDn+5EM3Pf+lBihhSlNVTR8rgQpB7cFHvM0AnUy8FMGxda1/3SIu6zNEpe6CM+CAy/4F8PqL2FxDfi4UPMA2OGykAyLGuVCRIhgMMpf326zU8N6BQkF1Pwsdjf+Q2t33pXsYANMh+KGQL81OvMVSdsJH+h99xQ==; 23:xSnOuKigiDnqtsLExq6FM3UnFTw1lBo43ZjrMMDXNHWr/QOQsgeHBOiMqdSJcIH0lKhQ7WzS19kj3kHT5cjOz4A0cIM6XsaiOlnDpYekajULyA1q6grZQ3LDqhVBU52sVoQzSBlUw/lXVsCGkFMXX1T7sI4Uu524Ydk6w9Kg5YXcXtO/o5OwfZc7iS+Hheae X-OriginatorOrg: nist.gov Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 21:45:21 -0000 > >If I understand your scenario correctly, as far as folks further along >the path are concerned, this is a replay attack by D. That D is doing >this to cover up something bad that A is doing to B and C is almost >irrelevant, as is the specific nature of whatever bad thing A is doing >to B and C. > >So, yeah, OK, it's a form of collusion, but it's not one that relies >on a weakness in the signature semantics, it's one that relies on lack >of protection against replay attacks, something the WG discussed and >rejected. Can't speak for anybody else, but I'm not particularly >interested in exhuming the replay horse at this late date. > It appears you agree that the two-update collusion scenario that=20 I described is feasible. It is basically another mechanism by which the=20 colluders seem to achieve the same effect as in David's collusion scenario. (I think so, but I'm open to being proven wrong about that.)=20 The latter, it appears, can be mitigated by signing 'all of the preceding=20 signed data', but not the former (two-update collusion).=20 Both scenarios or threats rely on intermediate ASes not verifying.=20 So both of these scenarios are mitigated by requiring intermediate=20 ASes to verify. This is the observation I would like to make. Since you made contrary comments, let me point out respectfully=20 that replay attack mitigation is in the requirements (RFC 7353): 4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design SHOULD provide a mechanism to control the window of exposure to replay attacks. And there is an active SIDR WG draft dealing with replay attack mitigation: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-04#section-4.2= =20 However, a solution for the specific collusion threat we are discussing=20 does not benefit at all from replay attack mitigation techniques. All that D is doing (in my example) is to hold the first update for 15 or 3= 0 seconds. The bgpsec-rollover draft proposes router key rollovers,=20 but (thank goodness) not on that small/tiny (seconds) time scale! Sriram =20 =20 =20 From nobody Fri Aug 28 19:30:52 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8266B1B3A8A for ; Fri, 28 Aug 2015 19:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 sfKd6oha1u7W for ; Fri, 28 Aug 2015 19:30:49 -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 A1C7C1B3A88 for ; Fri, 28 Aug 2015 19:30:49 -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 1ZVVup-0001BP-Sk; Sat, 29 Aug 2015 02:30:48 +0000 Date: Sat, 29 Aug 2015 04:30:49 +0200 Message-ID: From: Randy Bush To: Kotikalapudi Sriram In-Reply-To: References: <20150827175826.A35401AC51E2@minas-ithil.hactrn.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: [sidr] replay threats (was: draft-ietf-sidr-bgpsec-protocol-13's security guarantees) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 02:30:50 -0000 can we start a new thread for replay? randy