From sidr-bounces@ietf.org Tue Aug 5 03:30:47 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7B53A684E; Tue, 5 Aug 2008 03:30:47 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C4A3A684E for ; Tue, 5 Aug 2008 03:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79eBPede1iqu for ; Tue, 5 Aug 2008 03:30:45 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C9D0B3A67EC for ; Tue, 5 Aug 2008 03:30:45 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 71F8D268677; Tue, 5 Aug 2008 04:31:16 -0600 (MDT) Received: from [10.1.0.64] (host-87-74-63-191.dslgb.com [87.74.63.191]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 05 Aug 2008 04:31:16 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=87.74.63.191; client-port=52569; syn-fingerprint=65535:46:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: From: Danny McPherson To: Terry Manderson In-Reply-To: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 5 Aug 2008 04:31:14 -0600 References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> X-Mailer: Apple Mail (2.926) Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Jul 29, 2008, at 7:10 AM, Terry Manderson wrote: > > Does that help or add to your understand of where I'm coming from > with this work? Yes, it does, thanks for taking them time to explain your position. I don't have large concerns about this but I am interested in hearing from other folks that have or are planning to build tools here. Thanks Terry! -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Aug 5 22:00:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D7A3A685E; Tue, 5 Aug 2008 22:00:03 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0288C3A67DA; Tue, 5 Aug 2008 22:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080806050002.0288C3A67DA@core3.amsl.com> Date: Tue, 5 Aug 2008 22:00:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-manifests-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart 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 : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-02.txt Pages : 25 Date : 2008-08-05 This document defines a "manifest" for use in the Resource Public Key Infrastructure. A "manifest" is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to expose potential attacks against relying parties of the RPKI, such as a man-in-the middle withholding repository data or replaying stale repository data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-manifests-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-05214521.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Wed Aug 6 23:00:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641593A695B; Wed, 6 Aug 2008 23:00:03 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4D3243A68EF; Wed, 6 Aug 2008 23:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080807060001.4D3243A68EF@core3.amsl.com> Date: Wed, 6 Aug 2008 23:00:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rescerts-provisioning-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart 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 Protocol for Provisioning Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-rescerts-provisioning-03.txt Pages : 29 Date : 2008-08-06 This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rescerts-provisioning-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-06224915.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Fri Aug 8 07:30:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB97928C1AD; Fri, 8 Aug 2008 07:30:03 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B5A3A28C13A; Fri, 8 Aug 2008 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.B5A3A28C13A@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart 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 : Validation of Route Origination in BGP using the Resource Certificate PKI Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-00.txt Pages : 11 Date : 2008-08-06 This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-validation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08071851.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Fri Aug 8 07:35:10 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2DE28C137; Fri, 8 Aug 2008 07:35:10 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5560C3A6D59 for ; Fri, 8 Aug 2008 07:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVMGzE9t+u4p for ; Fri, 8 Aug 2008 07:35:08 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 4ACAB3A67B7 for ; Fri, 8 Aug 2008 07:35:08 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 07:35:07 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m78EZ4Q8014447 for ; Fri, 8 Aug 2008 09:35:07 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m78EZ5Qe004785 for ; Fri, 8 Aug 2008 09:35:05 -0500 Received: from localhost ([157.185.81.155]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:35:04 -0400 Date: Fri, 8 Aug 2008 10:35:03 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2008 14:35:04.0715 (UTC) FILETIME=[F29775B0:01C8F963] Subject: [sidr] acceptance of drafts as working group items X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Before the Dublin meeting, I requested working group input on adoption of three different drafts as work items. draft-huston-sidr-bogons draft-huston-sidr-repos-struct draft-huston-sidr-roa-validation While there has not been a huge outpouring of opinions on the question, all the responses received have been in favor of adoption of the drafts as work items. I declare that there is consensus to adopt these drafts as work items. Most of the comments were directed to the roa-validation draft, and I encourage the working group to continue the energy in working on that topic. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Aug 8 13:30:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39813A6AC0; Fri, 8 Aug 2008 13:30:03 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0A2AA3A6A1A; Fri, 8 Aug 2008 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808203002.0A2AA3A6A1A@core3.amsl.com> Date: Fri, 8 Aug 2008 13:30:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-bogons-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart 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 Bogon Origin Attestations (BOAs) Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-bogons-00.txt Pages : 15 Date : 2008-08-06 This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorized any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA, and also provides a means of verifying that BGP speaker is not using an AS as a BGP speaker without appropriate authority to use that AS. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bogons-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-bogons-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08131547.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Sat Aug 9 13:30:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515883A68D3; Sat, 9 Aug 2008 13:30:02 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B51603A68D3; Sat, 9 Aug 2008 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080809203001.B51603A68D3@core3.amsl.com> Date: Sat, 9 Aug 2008 13:30:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-repos-struct-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart 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 Resource Certificate Repository Structure Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-repos-struct-00.txt Pages : 12 Date : 2008-08-06 This document defines a profile for the structure of repositories that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests and a possible internal structure of a Repository Cache that is intended to facilitate synchronization across a distributed collection of repositories and facilitate certificate path construction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-repos-struct-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-repos-struct-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-09132920.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Aug 12 06:59:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E0F3A6A95; Tue, 12 Aug 2008 06:59:01 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957643A6AEC for ; Tue, 12 Aug 2008 06:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emCDbcYI5pi7 for ; Tue, 12 Aug 2008 06:58:58 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 5A45D3A6B12 for ; Tue, 12 Aug 2008 06:58:55 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 06:58:53 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m7CDwqOq025013; Tue, 12 Aug 2008 08:58:53 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m7CDwp7N003530; Tue, 12 Aug 2008 08:58:51 -0500 Received: from localhost ([157.185.81.155]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 09:58:51 -0400 Date: Tue, 12 Aug 2008 09:58:50 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Terry Manderson In-Reply-To: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> Message-ID: References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2008 13:58:51.0016 (UTC) FILETIME=[8C9E5080:01C8FC83] Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 29 Jul 2008, Terry Manderson wrote: > > > Hi Danny, > > There are several motivations for an additional / alternative mechanism for > retrieval as I see it. We know that RSYNC is a MUST in the SIA of the issued > RPKI certificate, and it then allows further multiple additional fetch URIs > where order of those URIs is the preferred order of use according to the > issuer. > > Putting on the hat of a relying party, if for some reason the highest order > URI is not immediately available it would be preferable to have access to a > heterogeneous method and location to retrieve the information. > > From the perspective of the issuer, I should (I think) do whatever it takes > to ensure that this information is available whenever a relying party > requires it. Having a second valid and known mechanism to do this helps > enormously for the obvious reasons. > > As Andy mentioned there are a plethora of tools and techniques for building > robust http(s) services, remembering that I'm not the only one who needs to > do this. Every single entity that issues their own RPKI objects needs to > place these objects in a repository, some will opt to use the repositories of > their RIRs, other will not. Those others will need to create a robust > repository structure and they may have their own preference for the server > infrastructure in their organisation, this allows them to put focus on their > preference, being either RSYNC or HTTP. > > The ubiquity of HTTP provides a strong platform for both server and client > development. I'm not sure it would expose an attack surface by adding http. > It may be that specifying just https may eliminate additional vectors. Do you > have any in mind? > > A social aspect that I'm cognisant of is that there appeared to be reluctance > by some parties to accept the rescerts draft because it had a non-ietf > reference implementation which potentially could raise issues about > interoperability between releases. This draft should nullify those as it does > provide an IETF standard for retrieval - so with luck allowing the pivotal > draft in question to gain adoption faster. Sorry for the late reply, I missed this remark. The objections I've heard raised about rsync are (1) it has NO specification beyond the code, which of course changes daily, leading to interoperability issues, should anyone else attempt to implement and (2) there's this license issue (formerly GPL v2, now GPL v3) [IANAL, YMMV]. Lack of *IETF* spec, or reference implementation of same, has not been a problem. --Sandy > > I'm not forgetting Rob A's mic comments about looking deeper into the TCP > behaviours and the overall efficiency of the entire retrieval of all the > objects at a publication point. Similarly Andy N's comments about making HTTP > 1.1 a MUST and also to look at connection creation in light of HTTPS. > > An attraction for me with the algorithm as stated is making the manifest the > synchronisation point and unambiguously giving the retrieval decisions to the > client, that is the client then has the explicit choice. > > Does that help or add to your understand of where I'm coming from with this > work? > > Cheers > Terry > > > On 29/07/2008, at 4:07 AM, Danny McPherson wrote: > >> Terry et al., >> I just had a chance to read this.. As I stated at the microphone, >> I'm quite interested in understanding the motivations for an >> alternative mechanism at this point, as I'm concerned that given >> all the other work that needs to be done, this will increase attack >> surfaces without adding needed capabilities. >> >> Do you mind iterating the motivations for this work, they're not >> in the current version of the draft? I'm genuinely interested in >> your input here, as given that you're going to be the one that has >> to implement, there's likely some obvious gaps (beyond "to >> scale") you're aiming to fill, gaps which aren't entirely obvious >> for me yet. >> >> Thanks! >> >> -danny > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Aug 12 08:18:08 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A973A6A40; Tue, 12 Aug 2008 08:18:08 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA9E3A6A40 for ; Tue, 12 Aug 2008 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIbhCKge3H-5 for ; Tue, 12 Aug 2008 08:18:05 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 7A17C3A69A9 for ; Tue, 12 Aug 2008 08:18:05 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 08:17:40 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m7CFHer8026900 for ; Tue, 12 Aug 2008 10:17:40 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m7CFHe7Q007419 for ; Tue, 12 Aug 2008 10:17:40 -0500 Received: from localhost ([157.185.81.155]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 11:17:40 -0400 Date: Tue, 12 Aug 2008 11:17:39 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2008 15:17:40.0235 (UTC) FILETIME=[8F73DDB0:01C8FC8E] Subject: [sidr] Fourth Nomcom 2008-9Call for Volunteers (fwd) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Joel Halpern, the NomCom chair, has requested that members of each wg be encouraged to volunteer for the nomcom process. Here is his message describing the process. --Sandy ---------- Forwarded message ---------- Date: Mon, 11 Aug 2008 18:18:47 -0700 From: NomCom Chair To: IETF Announcement list Subject: Fourth Nomcom 2008-9Call for Volunteers Fourth Nomcom 2008-9 Call for Volunteers! I am pleased to report that there are 91 volunteers whose qualifications have been confirmed by the secretariat. There is 1 more volunteers awaiting confirmation, as of Monday afternoon, August 11, 2008. However, I would still like more volunteers. You have until August 18th, 2008 as stated below. Please do so. The full details are included below. Please use the listed format, as that helps me and the secretariat do our jobs better. In a separate note, I will post the current list of verified Volunteers. Thank you, and I look forward to hearing from you, Joel M. Halpern Once again, the IETF nominating process has begun, and the community (and I) need your help. The IETF Nominating Committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The people who do that are 10 folks selected randomly from the pool of volunteers. To make this work well for the community, we need people to volunteer. Lots of people. Please! Volunteers must have attended 3 of the past 5 IETF meetings. As defined by RFC 3777, that is 3 of the past 5 meetings as of the time this announcement goes out to start the solicitation. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. Details on the nominating process can be found in RFC 3777. Below is the list of people and posts whose terms end with the March 2009 IETF meeting, and whose positions therefore the nominating committee is responsible for: IAOC: Jonne Soininen IAB: Loa Andersson Barry Leiba Kurtis Lindqvist Danny McPherson Dave Thaler Lixia Zhang IESG: IETF and IESG Chair: Russ Housley Applications Area (app): Chris Newman Internet Area (int): Mark Townsley Operations and Management Area (ops): Ronald Bonica Real-time Applications and Infrastructure Area (rai): Jon Peterson Routing Area (rtg): David Ward Security Area (sec): Tim Polk Transport Area (tsv): Lars Eggert Before volunteering, please think about whether you want to be considered for one of the above positions instead. If you are willing to volunteer, please send email before 5:00 pm EDT (2100 UTC/GMT) August 18, 2008 (otherwise, please read on) Please send email to me using the following skeleton: To: jmh@joelhalpern.com Subject: Nomcom 2008-9 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. During the IETF meeting in Dublin, responses will be somewhat slower, due to both my activities at the meeting and the secretariat's many activities in support of the meeting. I will try to send out at least a prompt confirmation that your email volunteering has been received. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term of this nomcom will begin in early September this year. We will be talking with folks at the Minneapolis IETF (if you are there. It is not mandatory that all nomcom members come to the meeting.) I hope to wrap up our primary selection work by mid-December, and we must complete our selection work by mid-January. We will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! I will be publishing a more thorough and precise target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you, and I hope to hear from you, Joel M. Halpern jmh@joelhalpern.com nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 13 00:54:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E800A3A69CF; Wed, 13 Aug 2008 00:54:40 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACD03A6990 for ; Wed, 13 Aug 2008 00:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoM4kBbe2X21 for ; Wed, 13 Aug 2008 00:54:39 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 0D7073A69CF for ; Wed, 13 Aug 2008 00:54:39 -0700 (PDT) Received: from [192.168.1.100] (dhcp245.apnic.net [202.12.29.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 864B7D5F2D; Wed, 13 Aug 2008 17:54:39 +1000 (EST) Message-Id: <6C4B5034-C563-49E4-8031-5FAB8308B48F@apnic.net> From: Terry Manderson To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 13 Aug 2008 17:54:38 +1000 References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> X-Mailer: Apple Mail (2.926) Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 12/08/2008, at 11:58 PM, Sandra Murphy wrote: >> >> >> A social aspect that I'm cognisant of is that there appeared to be >> reluctance by some parties to accept the rescerts draft because it >> had a non-ietf reference implementation which potentially could >> raise issues about interoperability between releases. This draft >> should nullify those as it does provide an IETF standard for >> retrieval - so with luck allowing the pivotal draft in question to >> gain adoption faster. > > Sorry for the late reply, I missed this remark. > > The objections I've heard raised about rsync are (1) it has NO > specification beyond the code, which of course changes daily, > leading to interoperability issues, should anyone else attempt to > implement and (2) there's this license issue (formerly GPL v2, now > GPL v3) [IANAL, YMMV]. Lack of *IETF* spec, or reference > implementation of same, has not been a problem. > > --Sandy Thanks for the clarification Sandy, I'll step back from the "non-ietf" point of view. (although in some ways it still drags on me, but it isn't a defining factor) I think your two points are far more salient in the broader view of the SIDR system architecture. Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 13 08:20:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9FA3A6ABE; Wed, 13 Aug 2008 08:20:28 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A333A6AC2 for ; Wed, 13 Aug 2008 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ4MsuG2BPfM for ; Wed, 13 Aug 2008 08:20:26 -0700 (PDT) Received: from nutshell.tislabs.com (nutshell.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id D9CD13A6ABE for ; Wed, 13 Aug 2008 08:20:25 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m7DFH8YK000268 for ; Wed, 13 Aug 2008 11:17:08 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFJayHa; Wed, 13 Aug 08 11:17:07 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id D3B9E3F44C; Wed, 13 Aug 2008 11:19:15 -0400 (EDT) To: sidr@ietf.org Message-Id: <20080813151915.D3B9E3F44C@pecan.tislabs.com> Date: Wed, 13 Aug 2008 11:19:15 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sandy@tislabs.com Subject: [sidr] WG LC on http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This initiates a WG LC on http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-11.txt. Given that it is summer vacation time, I am giving the LC a three week window. Replies by Sep 3, 2008, please. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 13 08:22:06 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB043A69E7; Wed, 13 Aug 2008 08:22:06 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A1F3A6AAA for ; Wed, 13 Aug 2008 08:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRxMXLchhgCw for ; Wed, 13 Aug 2008 08:22:04 -0700 (PDT) Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id 5C5453A6AD2 for ; Wed, 13 Aug 2008 08:21:50 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m7DFIVhK000280 for ; Wed, 13 Aug 2008 11:18:31 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJba4Ia; Wed, 13 Aug 08 11:18:31 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id AF3453F462; Wed, 13 Aug 2008 11:20:39 -0400 (EDT) To: sidr@ietf.org Message-Id: <20080813152039.AF3453F462@pecan.tislabs.com> Date: Wed, 13 Aug 2008 11:20:39 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sandy@tislabs.com Subject: [sidr] WG LC on draft-ietf-sidr-rpki-manifests-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This initiates a WG LC on http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-02.txt Given that it is summer vacation time, I am giving the LC a three week window. Replies by Sep 3, 2008, please. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 13 08:53:09 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03943A6AC3; Wed, 13 Aug 2008 08:53:09 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457D13A6A89; Wed, 13 Aug 2008 08:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxrxYdvVUUKO; Wed, 13 Aug 2008 08:53:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4ECBD3A683B; Wed, 13 Aug 2008 08:53:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,202,1217808000"; d="scan'208";a="74853451" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2008 15:51:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DFpiB7009507; Wed, 13 Aug 2008 08:51:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7DFpg3B024829; Wed, 13 Aug 2008 15:51:44 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 11:51:42 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 11:50:43 -0400 In-Reply-To: <6C4B5034-C563-49E4-8031-5FAB8308B48F@apnic.net> References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <6C4B5034-C563-49E4-8031-5FAB8308B48F@apnic.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <60997C53-7A54-4C2F-9B15-1C65B794BD23@cisco.com> From: David Ward Date: Wed, 13 Aug 2008 10:50:38 -0500 To: Terry Manderson X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 13 Aug 2008 15:50:43.0405 (UTC) FILETIME=[57ED57D0:01C8FD5C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1737; t=1218642704; x=1219506704; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[sidr]=20draft-sidr-fetch-00.txt |Sender:=20; bh=j+euB+fPFU25bQsGFhvBCVD/rXd4Mu038IeRSPrKNYQ=; b=YHJO3Z0+xM1q18cdYjf+6jFl1k0oalc4N1JL7gbT2xARnikn10mHkfqfBx 7uXdjGxVljk47LfzCOW4UpgYqTLeDxh3CrK/SJqdYTwmprH+prTmFUcLtKP3 zWvQ+W2OkN; Authentication-Results: sj-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IESG IESG , Ray Pelletier , sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Note that there are folks working to make the use of rsync a non- issue by clearing up the IPR and get reference implementations and docs together. Clearly rsync has been in use for millenia (in internet time scales). -DWard On Aug 13, 2008, at 2:54 AM, Terry Manderson wrote: > > On 12/08/2008, at 11:58 PM, Sandra Murphy wrote: >>> >>> >>> A social aspect that I'm cognisant of is that there appeared to >>> be reluctance by some parties to accept the rescerts draft >>> because it had a non-ietf reference implementation which >>> potentially could raise issues about interoperability between >>> releases. This draft should nullify those as it does provide an >>> IETF standard for retrieval - so with luck allowing the pivotal >>> draft in question to gain adoption faster. >> >> Sorry for the late reply, I missed this remark. >> >> The objections I've heard raised about rsync are (1) it has NO >> specification beyond the code, which of course changes daily, >> leading to interoperability issues, should anyone else attempt to >> implement and (2) there's this license issue (formerly GPL v2, now >> GPL v3) [IANAL, YMMV]. Lack of *IETF* spec, or reference >> implementation of same, has not been a problem. >> >> --Sandy > > > Thanks for the clarification Sandy, I'll step back from the "non- > ietf" point of view. (although in some ways it still drags on me, > but it isn't a defining factor) I think your two points are far > more salient in the broader view of the SIDR system architecture. > > Cheers > Terry > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 20 08:05:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0251F3A68AD; Wed, 20 Aug 2008 08:05:46 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0023A6AE3; Mon, 18 Aug 2008 13:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.293 X-Spam-Level: X-Spam-Status: No, score=-106.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip9ziTbivhHR; Mon, 18 Aug 2008 13:10:31 -0700 (PDT) Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by core3.amsl.com (Postfix) with ESMTP id 5CD9C3A6860; Mon, 18 Aug 2008 13:10:31 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 08198142212; Mon, 18 Aug 2008 13:10:38 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7SGrFKpZjri; Mon, 18 Aug 2008 13:10:28 -0700 (PDT) Received: from [10.1.1.130] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 692BE142215; Mon, 18 Aug 2008 13:10:28 -0700 (PDT) Message-Id: <4D922850-5E7B-45F4-BF6D-C33E3D3BB97E@osafoundation.org> From: Lisa Dusseault To: David Ward In-Reply-To: <60997C53-7A54-4C2F-9B15-1C65B794BD23@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 18 Aug 2008 13:10:29 -0700 References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <6C4B5034-C563-49E4-8031-5FAB8308B48F@apnic.net> <60997C53-7A54-4C2F-9B15-1C65B794BD23@cisco.com> X-Mailer: Apple Mail (2.928.1) X-Mailman-Approved-At: Wed, 20 Aug 2008 08:05:44 -0700 Cc: IESG IESG , sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org How active is the work on documenting RSYNC in a referencable, stable way? If I don't see an I-D, I tend to have low expectations of clearing up the reference in cases like these. I have sent mails to Andrew Tridgell in the past and gotten no response. I also corresponded with Dan Shearer (dan@shearer.org) who may be able to get us answers if we have specific questions about the IPR. Lisa On Aug 13, 2008, at 8:50 AM, David Ward wrote: > Note that there are folks working to make the use of rsync a non- > issue by clearing up the IPR and get reference implementations and > docs together. Clearly rsync has been in use for millenia (in > internet time scales). > > -DWard > > On Aug 13, 2008, at 2:54 AM, Terry Manderson wrote: > >> >> On 12/08/2008, at 11:58 PM, Sandra Murphy wrote: >>>> >>>> >>>> A social aspect that I'm cognisant of is that there appeared to >>>> be reluctance by some parties to accept the rescerts draft >>>> because it had a non-ietf reference implementation which >>>> potentially could raise issues about interoperability between >>>> releases. This draft should nullify those as it does provide an >>>> IETF standard for retrieval - so with luck allowing the pivotal >>>> draft in question to gain adoption faster. >>> >>> Sorry for the late reply, I missed this remark. >>> >>> The objections I've heard raised about rsync are (1) it has NO >>> specification beyond the code, which of course changes daily, >>> leading to interoperability issues, should anyone else attempt to >>> implement and (2) there's this license issue (formerly GPL v2, now >>> GPL v3) [IANAL, YMMV]. Lack of *IETF* spec, or reference >>> implementation of same, has not been a problem. >>> >>> --Sandy >> >> >> Thanks for the clarification Sandy, I'll step back from the "non- >> ietf" point of view. (although in some ways it still drags on me, >> but it isn't a defining factor) I think your two points are far >> more salient in the broader view of the SIDR system architecture. >> >> Cheers >> Terry >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Aug 24 20:36:36 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911603A6807; Sun, 24 Aug 2008 20:36:36 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190CD3A6807 for ; Sun, 24 Aug 2008 20:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUo4pO1uxSOM for ; Sun, 24 Aug 2008 20:36:34 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 0C1A03A63D3 for ; Sun, 24 Aug 2008 20:36:34 -0700 (PDT) Received: from puck.apnic.net (puck.apnic.net [202.12.29.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 02FC6D5F2D for ; Mon, 25 Aug 2008 13:36:25 +1000 (EST) Message-Id: <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 25 Aug 2008 13:36:25 +1000 References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> X-Mailer: Apple Mail (2.926) Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org .. and in the bad form of following-up to my own post. On 29/07/2008, at 11:10 PM, Terry Manderson wrote: > > The ubiquity of HTTP provides a strong platform for both server and > client development. I'm not sure it would expose an attack surface > by adding http. It may be that specifying just https may eliminate > additional vectors. Do you have any in mind? I had the opportunity on the weekend to catch up with an old colleague who now spends her time dealing with banking sector network security. After the usual banter about the selection of red wine we 'talked shop'. She was quite immovable in her view that regardless of the validation constructs of RPKI, the end to end fetching and publishing MUST be over a path that covers confidentiality, integrity, and availability. So in her eyes the important things are: - That when you establish a discussion with endpoint you are (to the best of current technology) certain it really is the endpoint. - That you are talking (unmolested) to the endpoint you think you are for the entirety of the session. - That what is retrieved by the client is audit-able at both the server and the client. - That retrievals are predictable, and perfectly repeatable. - That the client _never_ permits a downgrade, or unsecured retrieval of information - That Trust anchor management for both the client ssl and the PRKI is considered in such a way that it minimises the fact there is no such thing as trusted computing (her words). I asked for situations that she could identify (ie problems) and after the expected Kaminsky DNS issue discussion, I was showed the secret decoder ring and she suggested that I wasn't being paranoid enough given we are dealing with and constructing operational systems which affect the control plane. I'm not sure how this might reflect in the ARRRM draft yet, but I thought it worthwhile to share. Cheers, Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 25 07:42:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B28C3A6A20; Mon, 25 Aug 2008 07:42:05 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0258028C2A2 for ; Mon, 25 Aug 2008 07:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgtiLrEmslu7 for ; Mon, 25 Aug 2008 07:42:02 -0700 (PDT) Received: from davinci.fing.edu.uy (davinci.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id D25E43A6D01 for ; Mon, 25 Aug 2008 07:42:01 -0700 (PDT) Received: from [192.168.110.119] ([200.4.171.138]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id m7PEeBnp027846; Mon, 25 Aug 2008 11:40:35 -0300 (UYT) Message-Id: <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> From: Roque Gagliano To: Terry Manderson In-Reply-To: <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 25 Aug 2008 09:37:16 -0500 References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.926) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Mon, 25 Aug 2008 11:40:37 -0300 (UYT) X-Scanned-By: MIMEDefang 2.58 on 164.73.32.2 Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Terry, I wanted to ask you about this line: - ------------------ 4.1.1 e. Confirm that all of the objects listed in the downloaded manifest have been retrieved. - ------------------ What if I have a partial download of the URIs from the manifest? What if the successfully downloaded object files match the stored hashes? I personally believe that the manifest itself has to be only entirely download but partial downloads of object should be permitted. Regards, Roque On Aug 24, 2008, at 10:36 PM, Terry Manderson wrote: > > > .. and in the bad form of following-up to my own post. > > > On 29/07/2008, at 11:10 PM, Terry Manderson wrote: >> >> The ubiquity of HTTP provides a strong platform for both server and >> client development. I'm not sure it would expose an attack surface >> by adding http. It may be that specifying just https may eliminate >> additional vectors. Do you have any in mind? > > I had the opportunity on the weekend to catch up with an old colleague > who now spends her time dealing with banking sector network security. > After the usual banter about the selection of red wine we 'talked > shop'. > > She was quite immovable in her view that regardless of the validation > constructs of RPKI, the end to end fetching and publishing MUST be > over a path that covers confidentiality, integrity, and availability. > > So in her eyes the important things are: > - That when you establish a discussion with endpoint you are (to the > best of current technology) certain it really is the endpoint. > - That you are talking (unmolested) to the endpoint you think you are > for the entirety of the session. > - That what is retrieved by the client is audit-able at both the > server and the client. > - That retrievals are predictable, and perfectly repeatable. > - That the client _never_ permits a downgrade, or unsecured retrieval > of information > - That Trust anchor management for both the client ssl and the PRKI > is considered in such a way that it minimises the fact there is no > such thing as trusted computing (her words). > > I asked for situations that she could identify (ie problems) and after > the expected Kaminsky DNS issue discussion, I was showed the secret > decoder ring and she suggested that I wasn't being paranoid enough > given we are dealing with and constructing operational systems which > affect the control plane. > > I'm not sure how this might reflect in the ARRRM draft yet, but I > thought it worthwhile to share. > > Cheers, > Terry > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkiyw5wACgkQnk+WSgHpbO7jNgCg1dHvT3z3QcYbecGKxIEw/ZpE Nu0An2hhqQd35VT9GOXYYq3K8H1H3IZ3 =SzHP -----END PGP SIGNATURE----- _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 25 12:11:00 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19E33A68B3; Mon, 25 Aug 2008 12:11:00 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51D23A68B3 for ; Mon, 25 Aug 2008 12:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRD37QjsVPoG for ; Mon, 25 Aug 2008 12:10:58 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 267B43A67D4 for ; Mon, 25 Aug 2008 12:10:50 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 12:10:00 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m7PJ9xtc003947; Mon, 25 Aug 2008 14:09:59 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m7PJ9w3f027270; Mon, 25 Aug 2008 14:09:58 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.199]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 15:09:54 -0400 Date: Mon, 25 Aug 2008 15:09:54 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Roque Gagliano In-Reply-To: <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> Message-ID: References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2008 19:09:54.0691 (UTC) FILETIME=[2867DD30:01C906E6] Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mon, 25 Aug 2008, Roque Gagliano wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Terry, > > I wanted to ask you about this line: > - ------------------ > 4.1.1 > e. Confirm that all of the objects listed in the downloaded manifest > have been retrieved. > - ------------------ > > What if I have a partial download of the URIs from the manifest? What > if the successfully downloaded object files match the stored hashes? There's a "not" missing in here somewhere, I think. (Successful download and match of hashes seem like entirely good things.) > > I personally believe that the manifest itself has to be only entirely > download but partial downloads of object should be permitted. If you mean a partial download of some individual object, the signature of that object could not verify if the object was only partially downloaded. If you mean a partial download of the list of objects mentioned in the manifest, the manifest is designed particularly to detect when objects that should be in the repository are missing, so a partial download should not be permitted. Unless I've misunderstood you. --Sandy > > Regards, > > Roque > > > > On Aug 24, 2008, at 10:36 PM, Terry Manderson wrote: > >> >> >> .. and in the bad form of following-up to my own post. >> >> >> On 29/07/2008, at 11:10 PM, Terry Manderson wrote: >>> >>> The ubiquity of HTTP provides a strong platform for both server and >>> client development. I'm not sure it would expose an attack surface >>> by adding http. It may be that specifying just https may eliminate >>> additional vectors. Do you have any in mind? >> >> I had the opportunity on the weekend to catch up with an old colleague >> who now spends her time dealing with banking sector network security. >> After the usual banter about the selection of red wine we 'talked >> shop'. >> >> She was quite immovable in her view that regardless of the validation >> constructs of RPKI, the end to end fetching and publishing MUST be >> over a path that covers confidentiality, integrity, and availability. >> >> So in her eyes the important things are: >> - That when you establish a discussion with endpoint you are (to the >> best of current technology) certain it really is the endpoint. >> - That you are talking (unmolested) to the endpoint you think you are >> for the entirety of the session. >> - That what is retrieved by the client is audit-able at both the >> server and the client. >> - That retrievals are predictable, and perfectly repeatable. >> - That the client _never_ permits a downgrade, or unsecured retrieval >> of information >> - That Trust anchor management for both the client ssl and the PRKI >> is considered in such a way that it minimises the fact there is no >> such thing as trusted computing (her words). >> >> I asked for situations that she could identify (ie problems) and after >> the expected Kaminsky DNS issue discussion, I was showed the secret >> decoder ring and she suggested that I wasn't being paranoid enough >> given we are dealing with and constructing operational systems which >> affect the control plane. >> >> I'm not sure how this might reflect in the ARRRM draft yet, but I >> thought it worthwhile to share. >> >> Cheers, >> Terry >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkiyw5wACgkQnk+WSgHpbO7jNgCg1dHvT3z3QcYbecGKxIEw/ZpE > Nu0An2hhqQd35VT9GOXYYq3K8H1H3IZ3 > =SzHP > -----END PGP SIGNATURE----- > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 25 17:07:12 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801D63A6942; Mon, 25 Aug 2008 17:07:12 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978E628C126 for ; Mon, 25 Aug 2008 17:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syiJgqmXpUqg for ; Mon, 25 Aug 2008 17:07:10 -0700 (PDT) Received: from davinci.fing.edu.uy (davinci.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id E75573A685B for ; Mon, 25 Aug 2008 17:07:09 -0700 (PDT) Received: from [192.168.110.103] ([200.4.171.138]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id m7Q06pLL013175; Mon, 25 Aug 2008 21:06:53 -0300 (UYT) Message-Id: <206FD5F9-334D-4EC7-BD82-F282AF04BB5D@fing.edu.uy> From: Roque Gagliano To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 25 Aug 2008 19:06:40 -0500 References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.926) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Mon, 25 Aug 2008 21:06:57 -0300 (UYT) X-Scanned-By: MIMEDefang 2.58 on 164.73.32.2 Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0846841502==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0846841502== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-65-883831651" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-65-883831651 Content-Type: multipart/alternative; boundary=Apple-Mail-64-883831616 --Apple-Mail-64-883831616 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sandy, >> - ------------------ >> 4.1.1 >> e. Confirm that all of the objects listed in the downloaded manifest >> have been retrieved. >> - ------------------ >> >> What if I have a partial download of the URIs from the manifest? >> What >> if the successfully downloaded object files match the stored hashes? > > There's a "not" missing in here somewhere, I think. (Successful > download and match of hashes seem like entirely good things.) let me clarified what was trying to say. The question is about the word "all", what if you only succeed on download some of the objects in the manifest. Regards, Roque > > >> >> I personally believe that the manifest itself has to be only entirely >> download but partial downloads of object should be permitted. > > If you mean a partial download of some individual object, the > signature of that object could not verify if the object was only > partially downloaded. > > If you mean a partial download of the list of objects mentioned in > the manifest, the manifest is designed particularly to detect when > objects that should be in the repository are missing, so a partial > download should not be permitted. > > Unless I've misunderstood you. > > --Sandy > >> >> Regards, >> >> Roque >> >> >> >> On Aug 24, 2008, at 10:36 PM, Terry Manderson wrote: >> >>> >>> >>> .. and in the bad form of following-up to my own post. >>> >>> >>> On 29/07/2008, at 11:10 PM, Terry Manderson wrote: >>>> >>>> The ubiquity of HTTP provides a strong platform for both server and >>>> client development. I'm not sure it would expose an attack surface >>>> by adding http. It may be that specifying just https may eliminate >>>> additional vectors. Do you have any in mind? >>> >>> I had the opportunity on the weekend to catch up with an old >>> colleague >>> who now spends her time dealing with banking sector network >>> security. >>> After the usual banter about the selection of red wine we 'talked >>> shop'. >>> >>> She was quite immovable in her view that regardless of the >>> validation >>> constructs of RPKI, the end to end fetching and publishing MUST be >>> over a path that covers confidentiality, integrity, and >>> availability. >>> >>> So in her eyes the important things are: >>> - That when you establish a discussion with endpoint you are (to >>> the >>> best of current technology) certain it really is the endpoint. >>> - That you are talking (unmolested) to the endpoint you think you >>> are >>> for the entirety of the session. >>> - That what is retrieved by the client is audit-able at both the >>> server and the client. >>> - That retrievals are predictable, and perfectly repeatable. >>> - That the client _never_ permits a downgrade, or unsecured >>> retrieval >>> of information >>> - That Trust anchor management for both the client ssl and the PRKI >>> is considered in such a way that it minimises the fact there is no >>> such thing as trusted computing (her words). >>> >>> I asked for situations that she could identify (ie problems) and >>> after >>> the expected Kaminsky DNS issue discussion, I was showed the secret >>> decoder ring and she suggested that I wasn't being paranoid enough >>> given we are dealing with and constructing operational systems which >>> affect the control plane. >>> >>> I'm not sure how this might reflect in the ARRRM draft yet, but I >>> thought it worthwhile to share. >>> >>> Cheers, >>> Terry >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> >> iEYEARECAAYFAkiyw5wACgkQnk+WSgHpbO7jNgCg1dHvT3z3QcYbecGKxIEw/ZpE >> Nu0An2hhqQd35VT9GOXYYq3K8H1H3IZ3 >> =SzHP >> -----END PGP SIGNATURE----- >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> --Apple-Mail-64-883831616 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sandy,
- = ------------------
4.1.1
e. Confirm = that all of the objects listed in the downloaded = manifest
have been = retrieved.
- = ------------------

What if I have = a partial download of the URIs from the manifest? =  What
if the successfully = downloaded object files match the stored = hashes?

There's a "not" missing in here somewhere, I = think.   (Successful
download and match of hashes seem like = entirely good things.)

let me = clarified what was trying to say. The question is about the word "all", = what if you only succeed on download some of the objects in the = manifest.

Regards,
Roque

=





I personally = believe that the manifest itself has to be only = entirely
download but partial = downloads of object should be permitted.

If you mean = a partial download of some individual object, the signature of that = object could not verify if the object was only partially = downloaded.

If you mean a partial download of the list of objects = mentioned in the manifest, the manifest is designed particularly to = detect when objects that should be in the repository are missing, so a = partial download should not be permitted.

Unless I've = misunderstood you.

--Sandy


Regards,

Roque



On Aug 24, = 2008, at 10:36 PM, Terry Manderson wrote:



.. and in the bad form of = following-up to my own post.


On 29/07/2008, at 11:10 PM, = Terry Manderson wrote:

The = ubiquity of HTTP provides a strong platform for both server = and
client = development. I'm not sure it would expose an attack = surface
by = adding http. It may be that specifying just https may = eliminate
additional vectors. Do you have any in = mind?

I had the opportunity on the = weekend to catch up with an old = colleague
who now spends her time dealing = with banking sector network = security.
After the usual banter about the = selection of red wine we = 'talked
shop'.

She was quite immovable in her = view that regardless of the = validation
constructs of RPKI, the end to = end fetching and publishing MUST = be
over a path that covers confidentiality, integrity, and = availability.

So in her eyes the important = things are:
- That when you establish a = discussion with endpoint you are (to = the
best of current technology) certain it really is the = endpoint.
- That you are talking = (unmolested) to the endpoint you think you = are
for the entirety of the = session.
- That what is retrieved by the = client is audit-able at both = the
server and the = client.
= - That retrievals are predictable, and perfectly = repeatable.
- That the client _never_ permits = a downgrade, or unsecured = retrieval
of = information
- That Trust anchor management = for both the client ssl and the = PRKI
is considered in such a way that it minimises the fact = there is no
such thing as trusted computing = (her words).

I asked for situations that she = could identify (ie problems) and = after
the expected Kaminsky DNS issue discussion, I was showed = the secret
decoder ring and she suggested = that I wasn't being paranoid = enough
given we are dealing with and constructing operational = systems which
affect the control = plane.

I'm not sure how this might = reflect in the ARRRM draft yet, but = I
thought it worthwhile to = share.

Cheers,
Terry
_______________________________________________
sidr = mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

-----BEGIN PGP = SIGNATURE-----
Version: GnuPG = v1.4.8 (Darwin)

iEYEARECAAYFAkiyw5wACgkQnk+WSgHpbO7jNgCg1dHvT3z3QcYbecGKxIEw= /ZpE
Nu0An2hhqQd35VT9GOXYYq3K8H1H3IZ3
=3DSzHP
-----END = PGP SIGNATURE-----
_______________________________________________
sidr mailing = list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr


<= /html>= --Apple-Mail-64-883831616-- --Apple-Mail-65-883831651 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkizSRAACgkQnk+WSgHpbO4aBQCdG27/ipvqLMM23Aa0TjJKCml8 Cu4AnRxcpdORLPwR5fks+qmCJAWV2iLy =6eD2 -----END PGP SIGNATURE----- --Apple-Mail-65-883831651-- --===============0846841502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0846841502==-- From sidr-bounces@ietf.org Mon Aug 25 17:25:16 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535FD3A69E5; Mon, 25 Aug 2008 17:25:16 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27BEE3A6A74 for ; Mon, 25 Aug 2008 17:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fXHOeItQ1wy for ; Mon, 25 Aug 2008 17:25:14 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 4488A3A685A for ; Mon, 25 Aug 2008 17:25:14 -0700 (PDT) Received: from puck.apnic.net (puck.apnic.net [202.12.29.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 177B6D5F2D; Tue, 26 Aug 2008 10:25:06 +1000 (EST) Message-Id: <1CE7B96C-C18D-4F52-8833-953D1E4C33C8@apnic.net> From: Terry Manderson To: Roque Gagliano In-Reply-To: <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 26 Aug 2008 10:25:05 +1000 References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> X-Mailer: Apple Mail (2.926) Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Roque, On 26/08/2008, at 12:37 AM, Roque Gagliano wrote: > > > I wanted to ask you about this line: > - ------------------ > 4.1.1 > e. Confirm that all of the objects listed in the downloaded manifest > have been retrieved. > - ------------------ > > What if I have a partial download of the URIs from the manifest? > What if the successfully downloaded object files match the stored > hashes? > The intention is to make sure a local cache is a 1:1 match of the publish point such that RPKI validation will be (for the most part) effortless. If you validly retrieve on object (and the hash values match) you may be in danger of not having enough of the pki chain to successfully PRKI validate the object. > I personally believe that the manifest itself has to be only > entirely download but partial downloads of object should be permitted. > What I think you are saying that partial downloads of a publish point could be permitted, providing that all other parent objects associated with it have also been downloaded such that you can PPKI validate the 'single' object? Yes? Here you don't know what the parent objects are until you look in the object, and walk back up the tree using AIA values. Once you have all the objects you must then validate those in a top down sweep using the Trust Anchor. If the validation fails you need to discard all of those objects and try again (as expected). I won't walk away from a bottom up fetch process. If it is thought to be of value I can certainly look into including it the ARRRM draft and look at the issues of cost Vs utility. ie for long chains I have a feeling it would be very costly, but for short ones I think simple enough - which probably highlights a scaling issue. Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Aug 26 03:36:50 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C7A28B56A; Tue, 26 Aug 2008 03:36:50 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4F43A68B8 for ; Tue, 26 Aug 2008 03:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXJi7X8JwwAf for ; Tue, 26 Aug 2008 03:36:48 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id F1AE23A6AE7 for ; Tue, 26 Aug 2008 03:36:47 -0700 (PDT) Received: from [192.168.10.30] (124-171-133-121.dyn.iinet.net.au [124.171.133.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id BF009D5F39; Tue, 26 Aug 2008 20:36:36 +1000 (EST) Message-ID: <48B3DCB4.8040206@apnic.net> Date: Tue, 26 Aug 2008 20:36:36 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Roque Gagliano References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> <206FD5F9-334D-4EC7-BD82-F282AF04BB5D@fing.edu.uy> In-Reply-To: <206FD5F9-334D-4EC7-BD82-F282AF04BB5D@fing.edu.uy> X-Enigmail-Version: 0.95.7 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0565385428==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0565385428== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000702090101040106080402" This is a cryptographically signed message in MIME format. --------------ms000702090101040106080402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Roque Gagliano wrote: > Sandy, >>> - ------------------ >>> 4.1.1 >>> e. Confirm that all of the objects listed in the downloaded manifest >>> have been retrieved. >>> - ------------------ >>> >>> What if I have a partial download of the URIs from the manifest? What >>> if the successfully downloaded object files match the stored hashes? >> >> There's a "not" missing in here somewhere, I think. (Successful >> download and match of hashes seem like entirely good things.) > > let me clarified what was trying to say. The question is about the word > "all", what if you only succeed on download some of the objects in the > manifest. Details of how to handle various error cases are described in draft-ietf-sidr-rpki-manifests. In this case, in section 6.5: > If there exist files listed on the manifest that do not appear in the > repository, then these objects are likely to have been improperly > (via malice or accident) deleted from the manifest. A primary > purpose of manifests is to detect such deletions. Therefore, in such > a case this situation should result in a warning to the effect that: > "The following files that should have been present in the repository > at , are missing . This indicates an > attack against this publication point, or the repository, or an error > by the publisher." Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms000702090101040106080402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwODI2MTAzNjM2WjAj BgkqhkiG9w0BCQQxFgQUFfAgaqdTgmzGUPT0/RrRb8Vc9MgwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBAMPGGJSX0eKo FsWO+fd05v4vj1ceT5MvyHU9IFgn/+BCIINa9MekQ7MSq/e3WXTif6HUkxCZaU/YYF4PbvT4 YWOpXDQOIRmQI3HbrS4w1uQkDgPHCCuMnKGw9KRnHRJJeL4iFrq0HsjTEK52gMqL7CObRecv d1orj/O28BlQjorotlLA1QQ50C2yRPdxGITKOECK3ZKgJ2OHQ5bjYLOmrRelXp5ysbYFeMvw s240GvvFeS2eFDc35lFexFMiDEhT/oHs5zrYKNoH3H1UrkTbYw+WacpLQwgOFcZX5F/0s840 QYVNgmOMsEdIUqrJVWy+TJI5H3Zt5rZ8DUZLdIxchF0AAAAAAAA= --------------ms000702090101040106080402-- --===============0565385428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0565385428==-- From sidr-bounces@ietf.org Tue Aug 26 06:28:37 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC5E28C18D; Tue, 26 Aug 2008 06:28:37 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAACE28C103 for ; Tue, 26 Aug 2008 06:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UDDcRCS9R1K for ; Tue, 26 Aug 2008 06:28:35 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 2C4DF28C18D for ; Tue, 26 Aug 2008 06:28:28 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 06:28:29 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m7QDSRiG012539; Tue, 26 Aug 2008 08:28:28 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m7QDSR9g015174; Tue, 26 Aug 2008 08:28:27 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.102]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 09:28:26 -0400 Date: Tue, 26 Aug 2008 09:28:27 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Robert Loomans In-Reply-To: <48B3DCB4.8040206@apnic.net> Message-ID: References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> <206FD5F9-334D-4EC7-BD82-F282AF04BB5D@fing.edu.uy> <48B3DCB4.8040206@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 26 Aug 2008 13:28:26.0728 (UTC) FILETIME=[9F0A8E80:01C9077F] Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 26 Aug 2008, Robert Loomans wrote: > Roque Gagliano wrote: >> Sandy, >>>> - ------------------ >>>> 4.1.1 >>>> e. Confirm that all of the objects listed in the downloaded manifest >>>> have been retrieved. >>>> - ------------------ >>>> >>>> What if I have a partial download of the URIs from the manifest? What >>>> if the successfully downloaded object files match the stored hashes? >>> >>> There's a "not" missing in here somewhere, I think. (Successful >>> download and match of hashes seem like entirely good things.) >> >> let me clarified what was trying to say. The question is about the word >> "all", what if you only succeed on download some of the objects in the >> manifest. > > Details of how to handle various error cases are described in > draft-ietf-sidr-rpki-manifests. In this case, in section 6.5: > >> If there exist files listed on the manifest that do not appear in the >> repository, then these objects are likely to have been improperly >> (via malice or accident) deleted from the manifest. A primary ^^^^^^^^ repository? >> purpose of manifests is to detect such deletions. Therefore, in such >> a case this situation should result in a warning to the effect that: >> "The following files that should have been present in the repository >> at , are missing . This indicates an >> attack against this publication point, or the repository, or an error >> by the publisher." Yes, this is what I was trying to say - that the stated purpose of the manifest is to detect missing items, so permitting parital downloads of the list of objects would be counter to the purpose of the manifest. IMHO, of course. --Sandy > > Rob > > -- > Robert Loomans Email: robertl@apnic.net > Senior Software Engineer, APNIC Phone: +61 7 3858 3100 > http://www.apnic.net Fax: +61 7 3858 3199 > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 27 02:22:21 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55733A6A08; Wed, 27 Aug 2008 02:22:21 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30803A6A08 for ; Wed, 27 Aug 2008 02:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EuY2-Yj8PBF for ; Wed, 27 Aug 2008 02:22:20 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id D04A23A691F for ; Wed, 27 Aug 2008 02:22:19 -0700 (PDT) Received: from tinkerbell.nlnetlabs.nl (tinkerbell.nlnetlabs.nl [213.154.224.13]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m7R9MG76016396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Aug 2008 11:22:16 +0200 (CEST) (envelope-from benno@NLnetLabs.nl) Message-ID: <48B51CC8.2080600@NLnetLabs.nl> Date: Wed, 27 Aug 2008 11:22:16 +0200 From: Benno Overeinder User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: sidr@ietf.org X-Enigmail-Version: 0.95.7 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Wed, 27 Aug 2008 11:22:16 +0200 (CEST) Subject: [sidr] DefCon presentation on BGP hijacking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Our work on secure inter-domain routing got some attention from outside the IETF. "Revealed: The Internet's Biggest Security Hole", http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html I like the title of the post, well it got my attention... Cheers, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 27 02:24:47 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC4A3A6A08; Wed, 27 Aug 2008 02:24:47 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DC03A6A08 for ; Wed, 27 Aug 2008 02:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exz4OCgZNUz4 for ; Wed, 27 Aug 2008 02:24:45 -0700 (PDT) Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id D99683A691F for ; Wed, 27 Aug 2008 02:24:44 -0700 (PDT) Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 481BC35A54E; Wed, 27 Aug 2008 11:24:45 +0200 (CEST) Message-ID: <48B51D5C.8080300@spaghetti.zurich.ibm.com> Date: Wed, 27 Aug 2008 11:24:44 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Lightning/0.8 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Benno Overeinder References: <48B51CC8.2080600@NLnetLabs.nl> In-Reply-To: <48B51CC8.2080600@NLnetLabs.nl> X-Enigmail-Version: 0.95.7 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on abaddon.unfix.org X-Virus-Status: Clean Cc: sidr@ietf.org Subject: Re: [sidr] DefCon presentation on BGP hijacking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0491776546==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0491776546== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC001F174A1ECC7717749541E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC001F174A1ECC7717749541E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benno Overeinder wrote: > Our work on secure inter-domain routing got some attention from outside= > the IETF. >=20 > "Revealed: The Internet's Biggest Security Hole", > http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html >=20 > I like the title of the post, well it got my attention... It is about time: http://www.informs-sim.org/wsc04papers/038.pdf (a paper from 2004 btw ;) Also note that there is more text here: http://asert.arbornetworks.com/2008/08/internet-routing-insecurities-re-r= evealed/ Greets, Jeroen --------------enigC001F174A1ECC7717749541E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFItR1cKaooUjM+fCMRAnb+AJ9tRjAUxLsedX4kvjhD5GhfU6KnYgCeIsHQ 3zFQ/eXmy+tiqhvm+bz7azI= =y4x8 -----END PGP SIGNATURE----- --------------enigC001F174A1ECC7717749541E-- --===============0491776546== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0491776546==-- From sidr-bounces@ietf.org Wed Aug 27 08:46:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC2728C146; Wed, 27 Aug 2008 08:46:43 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA0C3A6B63 for ; Wed, 27 Aug 2008 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wza7aSGUfoqq for ; Wed, 27 Aug 2008 08:46:41 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id A9FBB3A6C76 for ; Wed, 27 Aug 2008 08:46:40 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 08:46:32 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m7RFkVV9031996; Wed, 27 Aug 2008 10:46:31 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m7RFkW3N025299; Wed, 27 Aug 2008 10:46:32 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.118]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 11:46:31 -0400 Date: Wed, 27 Aug 2008 11:46:31 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Benno Overeinder In-Reply-To: <48B51CC8.2080600@NLnetLabs.nl> Message-ID: References: <48B51CC8.2080600@NLnetLabs.nl> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 15:46:31.0927 (UTC) FILETIME=[13D15870:01C9085C] Cc: sidr@ietf.org Subject: Re: [sidr] DefCon presentation on BGP hijacking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org The presenter, Anton Kapela, pointed the nanog mailing list at his Defcon presentation: http://mailman.nanog.org/pipermail/nanog/2008-August/002811.html in case you want to read the background or follow the (short) thread http://mailman.nanog.org/pipermail/nanog/2008-August/002811.html if you want the presentation only. --Sandy On Wed, 27 Aug 2008, Benno Overeinder wrote: > Our work on secure inter-domain routing got some attention from outside > the IETF. > > "Revealed: The Internet's Biggest Security Hole", > http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html > > I like the title of the post, well it got my attention... > > Cheers, > > -- Benno > > -- > Benno J. Overeinder > NLnet Labs > http://www.nlnetlabs.nl/ > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 27 08:57:09 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7424F3A6B24; Wed, 27 Aug 2008 08:57:08 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09BD3A6A7C for ; Wed, 27 Aug 2008 08:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCa1T61uZl35 for ; Wed, 27 Aug 2008 08:56:58 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 704A73A6C89 for ; Wed, 27 Aug 2008 08:56:57 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 08:56:17 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m7RFuHSJ032202; Wed, 27 Aug 2008 10:56:17 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m7RFuCOm025787; Wed, 27 Aug 2008 10:56:14 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.118]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 11:56:11 -0400 Date: Wed, 27 Aug 2008 11:56:11 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Benno Overeinder In-Reply-To: Message-ID: References: <48B51CC8.2080600@NLnetLabs.nl> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 15:56:11.0505 (UTC) FILETIME=[6D45EE10:01C9085D] Cc: sidr@ietf.org Subject: Re: [sidr] DefCon presentation on BGP hijacking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Wed, 27 Aug 2008, Sandra Murphy wrote: > The presenter, Anton Kapela, pointed the nanog mailing list at his Defcon > presentation: > > http://mailman.nanog.org/pipermail/nanog/2008-August/002811.html > in case you want to read the background or follow the (short) thread > > http://mailman.nanog.org/pipermail/nanog/2008-August/002811.html Sorry, incomplete cut-and-paste. Try http://eng.5ninesdata.com/~tkapela/iphd-2.ppt I see that's referred to in a comment from Kapela in the wired article, as well. You might want to look at Kapela's nanog message, as it contains links to a lot of other presentations about the problem and operational "solutions". --Sandy > if you want the presentation only. > > --Sandy > > > On Wed, 27 Aug 2008, Benno Overeinder wrote: > >> Our work on secure inter-domain routing got some attention from outside >> the IETF. >> >> "Revealed: The Internet's Biggest Security Hole", >> http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html >> >> I like the title of the post, well it got my attention... >> >> Cheers, >> >> -- Benno >> >> -- >> Benno J. Overeinder >> NLnet Labs >> http://www.nlnetlabs.nl/ >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 27 11:20:15 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB633A6C65; Wed, 27 Aug 2008 11:20:15 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0973A6C64 for ; Wed, 27 Aug 2008 11:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhOA+vL1v1c3 for ; Wed, 27 Aug 2008 11:20:14 -0700 (PDT) Received: from out-71.smtp.ucla.edu (out-71.smtp.ucla.edu [169.232.46.168]) by core3.amsl.com (Postfix) with ESMTP id 6EE043A6C61 for ; Wed, 27 Aug 2008 11:20:14 -0700 (PDT) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.150]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id m7RIJFZD017407 for ; Wed, 27 Aug 2008 11:19:15 -0700 Received: from [172.24.76.220] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id m7RIJEfk030693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 27 Aug 2008 11:19:14 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <48B51D5C.8080300@spaghetti.zurich.ibm.com> References: <48B51CC8.2080600@NLnetLabs.nl> <48B51D5C.8080300@spaghetti.zurich.ibm.com> Message-Id: From: Ricardo Oliveira Date: Wed, 27 Aug 2008 11:19:15 -0700 To: sidr@ietf.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Spam-Hits: 0.654 X-Scanned-By: smtp.ucla.edu on 169.232.46.241 Subject: Re: [sidr] DefCon presentation on BGP hijacking X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This type of attack also described exhaustively in last year's Sigcomm paper: http://www.sigcomm.org/ccr/drupal/?q=node/264 Cheers, --Ricardo On Aug 27, 2008, at 2:24 AM, Jeroen Massar wrote: > Benno Overeinder wrote: >> Our work on secure inter-domain routing got some attention from >> outside >> the IETF. >> >> "Revealed: The Internet's Biggest Security Hole", >> http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html >> >> I like the title of the post, well it got my attention... > > It is about time: http://www.informs-sim.org/wsc04papers/038.pdf > (a paper from 2004 btw ;) > > Also note that there is more text here: > http://asert.arbornetworks.com/2008/08/internet-routing- > insecurities-re-revealed/ > > Greets, > Jeroen > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 27 18:08:06 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B293A6BEA; Wed, 27 Aug 2008 18:08:06 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0F628C2A7 for ; Wed, 27 Aug 2008 18:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGsutuHK78bl for ; Wed, 27 Aug 2008 18:08:05 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id B8A3F3A68BA for ; Wed, 27 Aug 2008 18:08:04 -0700 (PDT) Received: from [202.12.29.133] (dhcp133.apnic.net [202.12.29.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 3E553D5F31; Thu, 28 Aug 2008 11:07:59 +1000 (EST) Message-ID: <48B5FA6F.2000808@apnic.net> Date: Thu, 28 Aug 2008 11:07:59 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Sandra Murphy References: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> <113B8A82-064B-45F9-92C0-9AA0FE00159B@apnic.net> <1D41FD16-6243-4D10-8538-B9D7A4ECE763@fing.edu.uy> <206FD5F9-334D-4EC7-BD82-F282AF04BB5D@fing.edu.uy> <48B3DCB4.8040206@apnic.net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0230829592==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0230829592== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020309000906040702040306" This is a cryptographically signed message in MIME format. --------------ms020309000906040702040306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sandra Murphy wrote: >> Details of how to handle various error cases are described in >> draft-ietf-sidr-rpki-manifests. In this case, in section 6.5: >> >>> If there exist files listed on the manifest that do not appear in the >>> repository, then these objects are likely to have been improperly >>> (via malice or accident) deleted from the manifest. A primary > > ^^^^^^^^ > repository? I think so :) >>> purpose of manifests is to detect such deletions. Therefore, in such >>> a case this situation should result in a warning to the effect that: >>> "The following files that should have been present in the repository >>> at , are missing . This indicates an >>> attack against this publication point, or the repository, or an error >>> by the publisher." > > Yes, this is what I was trying to say - that the stated purpose of the > manifest is to detect missing items, so permitting parital downloads of > the list of objects would be counter to the purpose of the manifest. > IMHO, of course. Yes, a partial manifest is useless. You can't validate it. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms020309000906040702040306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwODI4MDEwNzU5WjAj BgkqhkiG9w0BCQQxFgQUlwTO2O74Cnlu5C5fHkzyST+5/W4wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBAKYKrsUvLdxO /jeFbAqkDjD5FrvwWncBCfnYhbSO5JKDFHreiYb66CVPxo86mWen98wJ/E0MveqpD3Wbm+xr jDBaSgyOWeG5FJZMiJUyb8QXSq9VUWs82B5KQ3/1Lvg/K1fw05wXWKzmuIqYvgZR1iQ+2aAI dH0EIghygWkN4zwktqCW92ZsHdfUwqURNtHiyOUKtjS+M6QD3XMLGsI3GRNae1PXJHJSlw+i lI2DQ22rfhstMh6Pwm25zqhjZW5T5f6kcEj4AdnfSN3CnoXLZDehB6KyU8fW9rOEf6iupPw5 3IbKzhfGNbSXPZwVdD1zxgbT1mhX5w1nHcAevYf8xo4AAAAAAAA= --------------ms020309000906040702040306-- --===============0230829592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0230829592==-- From sidr-bounces@ietf.org Fri Aug 29 02:59:36 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31DE3A67F9; Fri, 29 Aug 2008 02:59:35 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B37E3A67C1 for ; Fri, 29 Aug 2008 02:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W05I2ChSzyqD for ; Fri, 29 Aug 2008 02:59:33 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 696C63A67F9 for ; Fri, 29 Aug 2008 02:59:33 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Fri, 29 Aug 2008 02:59:25 PDT Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m7T9xPQO027639 for ; Fri, 29 Aug 2008 04:59:25 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m7T9xQAr024561 for ; Fri, 29 Aug 2008 04:59:26 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Aug 2008 05:59:25 -0400 Date: Fri, 29 Aug 2008 05:59:24 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 29 Aug 2008 09:59:25.0194 (UTC) FILETIME=[EAF196A0:01C909BD] Subject: [sidr] cancelled: WG LC on http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org The authors have requested that the WG LC on draft-ietf-sidr-res-certs-11.txt be cancelled. Implementaion experience with representation of the trust anchor and its use in path validation have led to approaches not in accordance with the text. They would like to revise the text to represent the experience. This should not be a large change and should be completed quickly. We can then reissue the last call. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Aug 29 06:39:48 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BF53A6A1F; Fri, 29 Aug 2008 06:39:48 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670E93A6A1F for ; Fri, 29 Aug 2008 06:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFjohZLnNc4V for ; Fri, 29 Aug 2008 06:39:46 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 4AF363A6A1E for ; Fri, 29 Aug 2008 06:39:46 -0700 (PDT) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7TDdZra030233 for ; Fri, 29 Aug 2008 09:39:36 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m7TDdRLZ001886 for ; Fri, 29 Aug 2008 09:39:27 -0400 Message-ID: <48B7FC07.9070703@nist.gov> Date: Fri, 29 Aug 2008 09:39:19 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: sidr@ietf.org X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: [sidr] Comments on draft-ietf-sidr-res-certs-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Below are my comments on draft-ietf-sidr-res-certs-11.txt. I understand that WG LC was just canceled, and that a new draft will be coming out soon, but I don't think that any of my comments will be affected by the impending changes. 1) Section 3 states: Unless specifically noted as being OPTIONAL, all the fields listed here MUST be present, and any other field MUST NOT appear in a conforming Resource Certificate. This seems overly constraining. There should be no need to prevent the inclusion of additional extensions as long as they are marked non-critical. 2) Sections 3.3 and 4.5: For consistency, the profile should either permit the use of SHA-1 or forbid the use of 1024 bit keys. Also, the second paragraph of section 3.3 should be deleted, since the same text already appears in section 3.8, and section 3.3 does not mention anything about key sizes. 3) Section 3.9.5 states: In this profile, the scope of the CRL is specified to be all certificates issued by this CA issuer using a given key pair. The scope of a CRL MUST be all certificates issued by the issuing CA unless the CRL includes an issuingDistributionPoint extension. So, if the scope of CRLs is to be limited to certificates signed with a given key pair, then the profile must either require inclusion of the issuingDistributionPoint extension in CRLs or forbid CAs from performing key rollover. The latter option may be implemented by having issuers change names whenever changing the key pair used to sign certificates. 4) Section 4.6.2 should say that revocation date "MUST NOT be a future date." The revoked certificates list cannot be used to list certificates that are not yet revoked, but that will be revoked in the future. 5) Section 5.1.1 (and several other places): The draft repeatedly states that subject names must be "unique per issuer in certificates issued by this issuer." While this is true, it may be misleading since it is a necessary, but not sufficient condition. X.509 requires that names be globally unique, so issuer and subject names must be unique within the scope of the entire RPKI. 6) The following two paragraphs in Section 5.3 (under BasicConstraints) seem inconsistent: If this is omitted then the CA will issue an end entity certificate with the BasicConstraints extension not present in the issued certificate. The CA MAY honour the SubjectType CA bit set to off (End Entity certificate request), in which case the corresponding end entity certificate will not contain a BasicConstraints extension. If failure to specify a SubjectType CA bit value always results in the issuance of an end entity certificate, why would it be acceptable for a CA to issue a CA certificate if the subject specifically requests an end entity certificate? 7) Section 5.3 (under SubjectInformationAccess): This section states that the certificate request for an EE certificate MUST include the SIA extension if the "EE certificate is intended for use in verifying multiple objects" or the "EE certificate is used to sign a single object". However, Section 3.9.7 states that inclusion of an SIA extension in EE certificates is optional (under some circumstances). Under what circumstances (if any) is it not a requirement to include an SIA extension in an EE certificate? 8) Section 6.3: Steps 2 and 3 seem unnecessary. Including these steps would seem require the use of path validation software that has been customized to only validate RPKI certificates rather than allowing for the use of off-the-shelf path validation software. What is the compelling reason for including these checks? 9) "certificate authority" should be replaced with "certification authority". 10) "Certificate Practice Statement" should be replaced with "Certification Practice Statement". 11) "certificate path" should be replaced with "certification path". _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr