From nobody Fri May 1 12:24:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90051B2DFF; Fri, 1 May 2015 12:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XozAfCv-rQw8; Fri, 1 May 2015 12:24:42 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB911B2DF9; Fri, 1 May 2015 12:24:42 -0700 (PDT) Received: by obbkp3 with SMTP id kp3so16333410obb.3; Fri, 01 May 2015 12:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Ueja8zgeZUzz1GPlSQ4cJg3LFOzwTXCBefa+H1GhtA=; b=awS2hwL9s4NUjZ2SflxZw7YKPVL00zlueLLKa8oXOotiwvWSdGpigOR6pXh8EDKokX S5CnnskJrMiR9b26h6qjiCu/pCfuajiRk1SIylaAzClx6mIpT2V/HiZM4XOp8GUS2Ut4 Fs9AK6ih8JyEg5eUjw90WGG+9FlbRxFI0r5wXgx1NYL1vQ05dxu21n+JMzbUpUUM3URU uov/zGRAQdpDWscO8prUSoeciF9tJuS7gUKPfQDhJjQIwIGGT4tAx9jaMTsn8GXYYqhf zlhPQHjX207Bymho2XYUrx3iqwEKmC93CMgNP8ttudy5E7Y3VbgZJa+3n7hhxpu/2ifY OjJQ== MIME-Version: 1.0 X-Received: by 10.183.1.41 with SMTP id bd9mr8756424obd.14.1430508281805; Fri, 01 May 2015 12:24:41 -0700 (PDT) Received: by 10.202.226.13 with HTTP; Fri, 1 May 2015 12:24:41 -0700 (PDT) In-Reply-To: <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> Date: Fri, 1 May 2015 15:24:41 -0400 Message-ID: From: Matthew Lepinski To: Iljitsch van Beijnum , Randy Bush Content-Type: multipart/alternative; boundary=001a1134ca9cfc3e5c05150a2939 Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 19:24:44 -0000 --001a1134ca9cfc3e5c05150a2939 Content-Type: text/plain; charset=UTF-8 My apologies for dropping the distinction between "Path Unsigned" (no BGPsec attribute) vs "Path Not Valid" (Path validation algorithm fails to validate). You are certainly correct that there are Nine possible states (and Randy's table is correct). That being said, I have some concern about treating "Path Unsigned" differently than "Path Not Valid", since it is trivial for a malicious adversary to transform "Path Not Valid" into "Path Unsigned" if doing so will yield better treatment for some bad route. On Thu, Apr 30, 2015 at 4:39 PM, Iljitsch van Beijnum wrote: > On 30 Apr 2015, at 19:48, Matthew Lepinski > wrote: > > > For path validation (as opposed to origin validation), the path > validation algorithm returns one of two states. That is, either an update > has a valid signed path or it doesn't. (We discussed previously in SIDR > whether there was a useful third case for path validation, and the working > group wasn't able to come up with one.) > > I think expired certificates qualifies. And a case can be made for strong > crypto algo vs weak crypto algo is a fourth one. > > > This means that there are six possible states that come from SIDR > validation (assuming you are using both origin validation and path > validation). That is, three possible origin validation states and two > possible path validation states yields six possible joint states. > > Actually nine, assuming < 100% BGPsec deployment: > > 1. BGPsec=valid, RPKI=valid > 2. BGPsec=valid, RPKI=unknown > 3. BGPsec=valid, RPKI=invalid > 4. no BGPsec, RPKI=valid > 5. no BGPsec, RPKI=unknown > 6. no BGPsecd, RPKI=invalid > 7. BGPsec=notvalid, RPKI=valid > 8. BGPsec=notvalid, RPKI=unknown > 9. BGPsec=notvalid, RPKI=invalid > > Only with type 1 can we be sure that the prefix is advertised legitimately. > > Type 5 indicates no BGPsec or RPKI deployment and may or may not be > legitimate. These should have a lower local_pref than type 1. Type 2 is > strange, but can probably be treated the same as type 5, or perhaps a > loc_pref higher than 5 but lower than 1. > > Types 3, 6 and 9 are bad news, as they may be unauthorized more specifics, > so it's important to filter these. > > Type 4 can happen because BGPsec hasn't been fully deployed yet (remember > that the whole path must support it while RPKI can be deployed by just the > "end" AS) but once that's no longer common it will be the attack vector of > choice because it's easy to fake the origin AS if there's no BGPsec, so at > some point, these need to be filtered, too. > > That leaves 7 and 8, which SHOULD be filtered if they're legitimate BGPsec > validation failures and not incidental mistakes such as expired > certificates. > > > it is perfectly fine for different operators to handle such cases > differently.) > > Famous last words. Obviously we don't want to be overly prescriptive, but > I don't think there's as much room for creativity as you suggest. > > > However, personally, for path validation, I would not recommend throwing > out all route advertisements where path validation returns invalid. That > is, if the only route you know of to get to a particular block of address > space has a signature that doesn't valid (or lack signatures because > someone in the middle doesn't have BGPsec turned on), I think it is > probably a good idea to use that route despite the lack of valid signature > chain. > > Actually I don't think that case can happen. Consider the following path: > > 6 5 4 3 2 1 > > If AS 4 doesn't support BGPsec but the others do, then AS 3 will convert > the BGPsec_Path to an AS_PATH, removing all the signatures. ASes 5 and 6 > are not in the position to repair this, so as far as they're concerned, the > path is completely unprotected. > > However, what you say here is problematic: > > > That is, if the only route you know of to get to a particular block of > address space has a signature that doesn't valid (or lack signatures > because someone in the middle doesn't have BGPsec turned on), I think it is > probably a good idea to use that route despite the lack of valid signature > chain. > > Considering whether a route is "the only route you know" is explicitly > forbidden by RFC 4271: > > "The function that calculates the degree of preference for a given > route SHALL NOT use any of the following as its inputs: the existence > of other routes, the non-existence of other routes, or the path > attributes of other routes." > > However, you can get the same result by simply giving the invalid path a > low local preference. > > However 2, the real problem with allowing prefixes that don't RPKI/BGPsec > validate is that these invalid prefixes could be more specifics of > legitimate prefixes, and no matter how high the local_pref of the valid > prefixes and low the local_pref of the invalid more specifics, the packets > will be forwarded as per the invalid more specifics. > > Therefore, the only workable approach is to completely filter out prefixes > that don't validate. > > However, the downside of such a strict policy is that if the certificates > used for BGPsec signatures expire, the path will become notvalid and the > associated prefixes disappear from the internet. That's why we need the > ability to treat paths that don't validate because of expired certificates > differently from paths that don't validate for other reasons. > > --001a1134ca9cfc3e5c05150a2939 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My apologies for dropping the distinction between "Pa= th Unsigned" (no BGPsec attribute) vs "Path Not Valid" (Path= validation algorithm fails to validate). You are certainly correct that th= ere are Nine possible states (and Randy's table is correct).

Th= at being said, I have some concern about treating "Path Unsigned"= differently than "Path Not Valid", since it is trivial for a mal= icious adversary to transform "Path Not Valid" into "Path Un= signed" if doing so will yield better treatment for some bad route.

On Thu, = Apr 30, 2015 at 4:39 PM, Iljitsch van Beijnum <iljitsch@muada.com>= wrote:
On 30 Apr= 2015, at 19:48, Matthew Lepinski <mlepinski.ietf@gmail.com> wrote:

> For path validation (as opposed to origin validation), the path valida= tion algorithm returns one of two states. That is, either an update has a v= alid signed path or it doesn't. (We discussed previously in SIDR whethe= r there was a useful third case for path validation, and the working group = wasn't able to come up with one.)

I think expired certificates qualifies. And a case can be made for s= trong crypto algo vs weak crypto algo is a fourth one.

> This means that there are six possible states that come from SIDR vali= dation (assuming you are using both origin validation and path validation).= That is, three possible origin validation states and two possible path val= idation states yields six possible joint states.

Actually nine, assuming < 100% BGPsec deployment:

1. BGPsec=3Dvalid, RPKI=3Dvalid
2. BGPsec=3Dvalid, RPKI=3Dunknown
3. BGPsec=3Dvalid, RPKI=3Dinvalid
4. no BGPsec, RPKI=3Dvalid
5. no BGPsec, RPKI=3Dunknown
6. no BGPsecd, RPKI=3Dinvalid
7. BGPsec=3Dnotvalid, RPKI=3Dvalid
8. BGPsec=3Dnotvalid, RPKI=3Dunknown
9. BGPsec=3Dnotvalid, RPKI=3Dinvalid

Only with type 1 can we be sure that the prefix is advertised legitimately.=

Type 5 indicates no BGPsec or RPKI deployment and may or may not be legitim= ate. These should have a lower local_pref than type 1. Type 2 is strange, b= ut can probably be treated the same as type 5, or perhaps a loc_pref higher= than 5 but lower than 1.

Types 3, 6 and 9 are bad news, as they may be unauthorized more specifics, = so it's important to filter these.

Type 4 can happen because BGPsec hasn't been fully deployed yet (rememb= er that the whole path must support it while RPKI can be deployed by just t= he "end" AS) but once that's no longer common it will be the = attack vector of choice because it's easy to fake the origin AS if ther= e's no BGPsec, so at some point, these need to be filtered, too.

That leaves 7 and 8, which SHOULD be filtered if they're legitimate BGP= sec validation failures and not incidental mistakes such as expired certifi= cates.

> it is perfectly fine for different operators to handle such cases diff= erently.)

Famous last words. Obviously we don't want to be overly prescrip= tive, but I don't think there's as much room for creativity as you = suggest.

> However, personally, for path validation, I would not recommend throwi= ng out all route advertisements where path validation returns invalid. That= is, if the only route you know of to get to a particular block of address = space has a signature that doesn't valid (or lack signatures because so= meone in the middle doesn't have BGPsec turned on), I think it is proba= bly a good idea to use that route despite the lack of valid signature chain= .

Actually I don't think that case can happen. Consider the follow= ing path:

6 5 4 3 2 1

If AS 4 doesn't support BGPsec but the others do, then AS 3 will conver= t the BGPsec_Path to an AS_PATH, removing all the signatures. ASes 5 and 6 = are not in the position to repair this, so as far as they're concerned,= the path is completely unprotected.

However, what you say here is problematic:

> That is, if the only route you know of to get to a particular block of= address space has a signature that doesn't valid (or lack signatures b= ecause someone in the middle doesn't have BGPsec turned on), I think it= is probably a good idea to use that route despite the lack of valid signat= ure chain.

Considering whether a route is "the only route you know" i= s explicitly forbidden by RFC 4271:

=C2=A0 "The function that calculates the degree of preference for a gi= ven
=C2=A0 =C2=A0route SHALL NOT use any of the following as its inputs: the ex= istence
=C2=A0 =C2=A0of other routes, the non-existence of other routes, or the pat= h
=C2=A0 =C2=A0attributes of other routes."

However, you can get the same result by simply giving the invalid path a lo= w local preference.

However 2, the real problem with allowing prefixes that don't RPKI/BGPs= ec validate is that these invalid prefixes could be more specifics of legit= imate prefixes, and no matter how high the local_pref of the valid prefixes= and low the local_pref of the invalid more specifics, the packets will be = forwarded as per the invalid more specifics.

Therefore, the only workable approach is to completely filter out prefixes = that don't validate.

However, the downside of such a strict policy is that if the certificates u= sed for BGPsec signatures expire, the path will become notvalid and the ass= ociated prefixes disappear from the internet. That's why we need the ab= ility to treat paths that don't validate because of expired certificate= s differently from paths that don't validate for other reasons.


--001a1134ca9cfc3e5c05150a2939-- From nobody Fri May 1 12:58:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7861A8A39; Fri, 1 May 2015 12:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LVMjegdjFrX; Fri, 1 May 2015 12:58:44 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00921A8858; Fri, 1 May 2015 12:58:43 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t41JwLu8035331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2015 21:58:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 1 May 2015 21:58:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> To: Matthew Lepinski X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 19:58:45 -0000 On 01 May 2015, at 21:24, Matthew Lepinski = wrote: > You are certainly correct that there are Nine possible states (and = Randy's table is correct). Randy's table? I must have missed that one. > That being said, I have some concern about treating "Path Unsigned" = differently than "Path Not Valid", since it is trivial for a malicious = adversary to transform "Path Not Valid" into "Path Unsigned" if doing so = will yield better treatment for some bad route. That's a good point. But then, how do you treat those? By filtering the = affected prefixes? You can only do that once _all_ paths are signed. So basically, we're stuck with our AS path filters until BGPsec = deployment hits 100%. It would have been better if BGPsec would have had provisions for = partial deployment, so that you can have a path that is partially BGPsec = protected even if it can't be fully be BGPsec-protected. That way, the = filtering issue shrinks in scope as the BGPsec-enabled core grows and = non-BGPsec branches turn into leaves and finally go away.= From nobody Sat May 2 19:52:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4CA1A004D; Sat, 2 May 2015 19:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DONufRfeYVt; Sat, 2 May 2015 19:51:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35BD1A004C; Sat, 2 May 2015 19:51:55 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) with Microsoft SMTP Server (TLS) id 15.1.154.19; Sun, 3 May 2015 02:51:37 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0154.018; Sun, 3 May 2015 02:51:37 +0000 From: "Sriram, Kotikalapudi" To: Iljitsch van Beijnum , Matthew Lepinski Thread-Topic: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQg23hvPefCdVsC0+PANQ5UDQxHp1mBKmAgAF9bICAAAl4AIABfEbj Date: Sun, 3 May 2015 02:51:36 +0000 Message-ID: <1430621496060.84229@nist.gov> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.220.209] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0793; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0793; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793; x-forefront-prvs: 056544FBEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2950100001)(2900100001)(54356999)(76176999)(50986999)(86362001)(36756003)(87936001)(2656002)(46102003)(92566002)(93886004)(40100003)(62966003)(77156002)(122556002)(5001960100002)(5001920100001)(102836002)(15975445007)(77096005)(66066001)(19580395003)(99286002)(5001770100001)(230783001)(117636001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0793; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2015 02:51:36.7001 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0793 Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 02:51:58 -0000 >It would have been better if BGPsec would have had provisions for partial = deployment,=20 >so that you can have a path that is partially BGPsec protected even if it = can't be fully be BGPsec-protected.=20 >That way, the filtering issue shrinks in scope as the BGPsec-enabled core = grows=20 >and non-BGPsec branches turn into leaves and finally go away. =93path that is partially BGPsec protected=94 =96 I wouldn=92t call that = =93partial deployment=94. =20 That is just partial path signing. Partial deployment, on the other hand, connotes that there are islands with= in which=20 BGPsec is deployed, and the rest of Internet is non-BGPsec.=20 In this sense, partial deployment is synonymous with incremental deployment= . =20 Let us discuss incremental deployment and =93path that is partially BGPsec = protected=94 separately. (1) Incremental Deployment: BGPsec is amenable to incremental deployment, and does provide benefit to e= arly adopters within BGPsec islands.=20 For examples, you can have a BGPsec island in Asia in which, say, 30K prefi= xes are originated.=20 And another BGPsec island in Europe in which, say, 50K prefixes are origina= ted.=20 All prefix-routes for those 30K (or 50K) prefixes within an island have the= full protection of=20 BGPsec while they originate from an AS within the island and propagate full= y signed to other=20 ASes within the same island. When those prefix-routes cross from a BGPsec i= sland=20 into non-BGPsec Internet, then they lose the signatures entirely and lose t= he protection. Down the road, when ASes from the two islands in this example interconnect = using=20 BGPsec peering, then the combined BGPsec island will be much bigger, provid= ing protection=20 for prefix-routes for all 80K prefixes while they originate from an AS with= in the combined island=20 and propagate fully signed to other ASes within the combined island.=20 So incremental deployment can start within islands,=20 and grow as islands expand and/or interconnect with each other. Some additional thoughts on incremental deployment can be found in Section = 6.3 of=20 the BGPSEC design discussion document: https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-07#page-21=20 =20 (2) =93path that is partially BGPsec protected=94 or Partial Path Signing If an update with partially signed path is given some sort of preference ov= er an unsigned update=20 that would encourage cut-and-paste attacks. Additional thoughts on why par= tial path signing=20 is disallowed can be found in Section 6.4 of the BGPSEC design discussion d= ocument: https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-07#page-21=20 =20 Sriram From nobody Tue May 5 06:35:45 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1F71ACCF6 for ; Tue, 5 May 2015 06:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKNhsXvr2n7I for ; Tue, 5 May 2015 06:35:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C245A1ACC91 for ; Tue, 5 May 2015 06:35:40 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50700 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ypd0d-000CiR-HF for sidr@ietf.org; Tue, 05 May 2015 09:35:39 -0400 Message-ID: <5548C72B.5000800@bbn.com> Date: Tue, 05 May 2015 09:35:39 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> In-Reply-To: <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 13:35:43 -0000 Iljitsch, > On 30 Apr 2015, at 19:48, Matthew Lepinski wrote: > >> For path validation (as opposed to origin validation), the path validation algorithm returns one of two states. That is, either an update has a valid signed path or it doesn't. (We discussed previously in SIDR whether there was a useful third case for path validation, and the working group wasn't able to come up with one.) > I think expired certificates qualifies. And a case can be made for strong crypto algo vs weak crypto algo is a fourth one. I'm puzzled by the comment re crypto strength. We don't have the TLS situation where there are lots of alg suites. We have one suite, and a well-documented (RFC 6915) process for transitioning to a next suite. Steve From nobody Tue May 5 13:47:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0511ACD6E; Tue, 5 May 2015 13:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E87jnYQG_H3w; Tue, 5 May 2015 13:47:00 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D291ACD68; Tue, 5 May 2015 13:47:00 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t45KkZHr097680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2015 22:46:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <1430621496060.84229@nist.gov> Date: Tue, 5 May 2015 22:46:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> <1430621496060.84229@nist.gov> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:47:02 -0000 On 03 May 2015, at 4:51, Sriram, Kotikalapudi = wrote: > =93path that is partially BGPsec protected=94 =96 I wouldn=92t call = that =93partial deployment=94. =20 > That is just partial path signing. The latter is a way to allow for the former. > Partial deployment, on the other hand, connotes that there are islands = within which=20 > BGPsec is deployed, and the rest of Internet is non-BGPsec. Hm, could be islands of BGPsec in a non-BGPsec sea or islands of = non-BGPsec in a BGPsec sea. In practice, what will happen very soon is = that there will be a BGPsec core with non-BGPsec leaves and branches. > (1) Incremental Deployment: > BGPsec is amenable to incremental deployment, and does provide benefit = to early adopters within BGPsec islands.=20 > For examples, you can have a BGPsec island in Asia in which, say, 30K = prefixes are originated.=20 > And another BGPsec island in Europe in which, say, 50K prefixes are = originated.=20 > All prefix-routes for those 30K (or 50K) prefixes within an island = have the full protection of=20 > BGPsec while they originate from an AS within the island and propagate = fully signed to other=20 > ASes within the same island. Sure. But what if one of those BGPsec-capable ASes has a customer that = doesn't run BGPsec? So: 5+ 4+ 3+ 2+ 1- (where + is BGPsec and - is no BGPsec) In this case the entire path will be unprotected, even though four of = the five ASes in the path are capable of using BGPsec. I fair argument = can be made that if it's only the origin AS that's non-BGPsec, the = protection afforded is very nearly as good as in the case where the = complete path is BGPsec-protected. And in general it would be better for BGPsec to be more opportunistic = and protect whatever it can protect, even if that falls short of full = end-to-end protection. Every protected hop takes away an opportunity for = malicious parties to do bad things.= From nobody Tue May 5 13:59:39 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4B01B29A4 for ; Tue, 5 May 2015 13:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI_qw6fWI0h6 for ; Tue, 5 May 2015 13:59:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BF91AD4A1 for ; Tue, 5 May 2015 13:59:36 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:52095 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YpjwF-000PA3-GA for sidr@ietf.org; Tue, 05 May 2015 16:59:35 -0400 Message-ID: <55492F37.3000308@bbn.com> Date: Tue, 05 May 2015 16:59:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> <1430621496060.84229@nist.gov> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:59:38 -0000 Iljitsch, The topic of partial path signing was explored in detail and rejected for a couple of reasons. It was way too complex to figure out how an AS could rely on partial path sig info, and there appeared to be a lot of ways to exploit the new attack surfaces created by partially signed paths. Steve From nobody Tue May 5 16:03:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7956C1A896C; Tue, 5 May 2015 16:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hM3yvrNvWT6; Tue, 5 May 2015 16:02:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3231C1A894C; Tue, 5 May 2015 16:02:55 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) with Microsoft SMTP Server (TLS) id 15.1.154.19; Tue, 5 May 2015 23:02:53 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0154.018; Tue, 5 May 2015 23:02:53 +0000 From: "Sriram, Kotikalapudi" To: Iljitsch van Beijnum Thread-Topic: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQg23hvPefCdVsC0+PANQ5UDQxHp1mBKmAgAF9bICAAAl4AIABfEbjgATaiQCAAAzNsA== Date: Tue, 5 May 2015 23:02:52 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> <1430621496060.84229@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muada.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0793; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0793; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793; x-forefront-prvs: 0567A15835 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(99286002)(86362001)(76576001)(2950100001)(92566002)(50986999)(2900100001)(33656002)(54356999)(76176999)(46102003)(93886004)(106116001)(15975445007)(102836002)(40100003)(122556002)(62966003)(77156002)(77096005)(110136002)(5001960100002)(74316001)(19580395003)(87936001)(66066001)(2656002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0793; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2015 23:02:52.9802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0793 Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 23:02:57 -0000 >In practice, what will happen very soon is that there will be a >BGPsec core with non-BGPsec leaves and branches. That is a possibility. To encourage leaves (stub ASes) to get on board with= BGPsec, the specification=20 allows for BGPsec capability to be negotiated independently in each directi= on (send and receive). This means that a stub AS can negotiate with its upstream to send signed up= dates (to the upstream)=20 but receive only unsigned updates (i.e. trusts its upstream). Thus it avoids processing and memory costs associated with processing signe= d updates and storing them.=20 This facilitates the stub AS to avoid expensive HW upgrade, but still benef= it from BGPsec. Please see Section 2 of the BGPsec specification. Also see Sections 6.5 and= 6.6 in the=20 BGPSEC design discussion document: http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-07#page-21=20 >Sure. But what if one of those BGPsec-capable ASes has a customer that doe= sn't >run BGPsec? So: > >5+ 4+ 3+ 2+ 1- > >(where + is BGPsec and - is no BGPsec) > >In this case the entire path will be unprotected, even though four of the = five >ASes in the path are capable of using BGPsec. I fair argument can be made = that >if it's only the origin AS that's non-BGPsec, the protection afforded is v= ery nearly >as good as in the case where the complete path is BGPsec-protected. > Steve Kent summed it up nicely (in his most recent post on the SIDR list) a= bout the pitfalls=20 of allowing partial path signing.=20 In your specific example above, let us say, there is also an 8+ who is *mal= icious* and a BGPsec neighbor of 5+. 8+ does not peer with 1-, but nevertheless sends an update with the followi= ng malicious AS path to 5+: 8+ 1- (for the same NLRI as in your example above) 8+ is basically faking that it got an unsigned update from 1- and=20 it is forwarding the same to 5+ with a signature (i.e. 8+ signing to 5+). How will 5+ know that the partially signed update with AS path of {4+ 3+ 2+= 1-} is legitimate=20 and that the other partially signed update with AS path {8+ 1-} is maliciou= s?=20 It has no way of knowing that. Sriram =20 From nobody Sun May 10 03:51:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F3E1A6EF9 for ; Sun, 10 May 2015 03:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxbmciqNRS6M for ; Sun, 10 May 2015 03:51:12 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [67.18.34.22]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1676F1A6EF2 for ; Sun, 10 May 2015 03:51:12 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id A0F851195D3BF; Sun, 10 May 2015 05:51:11 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 925751195D3A1 for ; Sun, 10 May 2015 05:51:11 -0500 (CDT) Received: from [193.0.27.159] (port=61652 helo=dhcp-27-159.ripemtg.ripe.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YrOpC-0003rR-3V; Sun, 10 May 2015 05:51:10 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <55394D15.4040104@bbn.com> Date: Sun, 10 May 2015 12:51:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24D2454E-9407-4FFB-BEA3-998E008D0C8D@ieca.com> References: <20150420173628.D2FEA180092@rfc-editor.org> <553687A5.50503@bbn.com> <8F0E0F5C-5A48-4A43-83F0-5DCB63AF3BAD@ieca.com> <55394D15.4040104@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 193.0.27.159 X-Exim-ID: 1YrOpC-0003rR-3V X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-27-159.ripemtg.ripe.net) [193.0.27.159]:61652 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 13 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: db3546@att.com, sidr wg list , Chris Morrow , Sandra Murphy , RFC Errata System Subject: Re: [sidr] [Editorial Errata Reported] RFC6485 (4340) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 10:51:12 -0000 On Apr 23, 2015, at 21:50, Richard Hansen wrote: > On 2015-04-21 18:49, Sean Turner wrote: >> so I'd probably just leave it. >=20 > Are you saying that the errata process is too heavyweight for a minor > editorial typo like this? If so, is there a more appropriate way to > report an editorial typo so that it will be fixed in a bis if/when one > is ever produced? >=20 > Thanks, > Richard Sorry definitely wasn't clear there - errata is the right way to handle = this. I jumped to how I=92d mark it if I were AD :) There=92s three = ways: approved, rejected, and HDFU (hold for document update). I was = opting for HFDU. spt= From nobody Sun May 10 16:13:19 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6191A1A0B for ; Sun, 10 May 2015 16:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erY1SDTLRCMZ for ; Sun, 10 May 2015 16:13:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4DA1AC432 for ; Sun, 10 May 2015 16:13:16 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:45895) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YraPD-000OKS-1j; Sun, 10 May 2015 19:13:07 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id A20AA401E0 Message-ID: <554FE602.9020207@bbn.com> Date: Sun, 10 May 2015 19:13:06 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sean Turner References: <20150420173628.D2FEA180092@rfc-editor.org> <553687A5.50503@bbn.com> <8F0E0F5C-5A48-4A43-83F0-5DCB63AF3BAD@ieca.com> <55394D15.4040104@bbn.com> <24D2454E-9407-4FFB-BEA3-998E008D0C8D@ieca.com> In-Reply-To: <24D2454E-9407-4FFB-BEA3-998E008D0C8D@ieca.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: db3546@att.com, sidr wg list , Chris Morrow , Sandra Murphy , RFC Errata System Subject: Re: [sidr] [Editorial Errata Reported] RFC6485 (4340) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 23:13:18 -0000 On 2015-05-10 06:51, Sean Turner wrote: > On Apr 23, 2015, at 21:50, Richard Hansen wrote: >> On 2015-04-21 18:49, Sean Turner wrote: >>> so I'd probably just leave it. >>=20 >> Are you saying that the errata process is too heavyweight for a=20 >> minor editorial typo like this? If so, is there a more appropriate >> way to report an editorial typo so that it will be fixed in a bis >> if/when one is ever produced? >=20 > Sorry definitely wasn't clear there - errata is the right way to=20 > handle this. I jumped to how I=92d mark it if I were AD :) There=92s=20 > three ways: approved, rejected, and HDFU (hold for document update). Ah, that makes sense. Thanks for the clarification -- I'm still new to IETF procedures, so this helps. > I was opting for HFDU. The meaning of HFDU wasn't clear to me until I found [1]. I agree with you -- HFDU does seem like the right choice here. [1] https://www.ietf.org/iesg/statement/errata-processing.html Thank you for your feedback, Richard From nobody Mon May 11 08:27:06 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373531A9045; Mon, 11 May 2015 08:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AF0lOD8VBBB; Mon, 11 May 2015 08:27:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D3D1A90A7; Mon, 11 May 2015 08:26:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511152616.29302.55475.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 08:26:16 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:27:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Securing RPSL Objects with RPKI Signatures Authors : Robert Kisteleki Brian Haberman Filename : draft-ietf-sidr-rpsl-sig-07.txt Pages : 13 Date : 2015-05-11 Abstract: This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpsl-sig-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 11 08:42:21 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA281ACD49 for ; Mon, 11 May 2015 08:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjAi3RvBpEFT for ; Mon, 11 May 2015 08:42:19 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5D71ACD74 for ; Mon, 11 May 2015 08:42:10 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 503008812D for ; Mon, 11 May 2015 08:42:09 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id F22A013682A3 for ; Mon, 11 May 2015 08:42:08 -0700 (PDT) Message-ID: <5550CDC9.4030105@innovationslab.net> Date: Mon, 11 May 2015 11:42:01 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20150511152616.29302.55475.idtracker@ietfa.amsl.com> In-Reply-To: <20150511152616.29302.55475.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q79uaRsbtV9VbT7PAnpwpNFXu7tQxxxr6" Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:42:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q79uaRsbtV9VbT7PAnpwpNFXu7tQxxxr6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, On 5/11/15 11:26 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. >=20 > Title : Securing RPSL Objects with RPKI Signatures > Authors : Robert Kisteleki > Brian Haberman > Filename : draft-ietf-sidr-rpsl-sig-07.txt > Pages : 13 > Date : 2015-05-11 >=20 This update incorporates two changes from the discussion at the previous IETF meeting: 1. Removed the "o" attribute for multiple signatures 2. Adds a reference to RFC 6481 when discussing certificate repository in the "c" attribute. Regards, Brian --q79uaRsbtV9VbT7PAnpwpNFXu7tQxxxr6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVUM3JAAoJEBOZRqCi7goqkAYH/AmAXl1hc10YCL6O2LFG08sH EXIsvZvoFuaxUJrZa/pP58SATqiqQGf58lwWXcFQ5eFgrnKTjYe7QYkUkR/p1iUf mYX13WM94u5sGmb3vE9XC7TSx+vdtOtF3xvB8ieApFmEGRMUAuTr6z0YM4iexfWm 8O7/ScpJ45Oy93mAWDg1z/9h2mR39A+mRHorP0lOIjo85i7vmZeUyS4817rhTlTT 3OC92L3DN/Ig8AUn+IXTbrOW8Sox5DO3yOVcjMDP5CzUcyRzcqu2C+rDZ7MY4PBn tmaHwKnep8qYsX66Ip5WyKCciIJMCaiaxNcX3QGgyNMj/mtlOla3+/0V8OpsRog= =nf4C -----END PGP SIGNATURE----- --q79uaRsbtV9VbT7PAnpwpNFXu7tQxxxr6-- From nobody Mon May 11 15:26:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25681A9110 for ; Mon, 11 May 2015 15:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMZSFfsdIPGm for ; Mon, 11 May 2015 15:26:13 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7C41A90EA for ; Mon, 11 May 2015 15:26:12 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1A0E028B0042 for ; Mon, 11 May 2015 18:26:12 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D86441F8035; Mon, 11 May 2015 18:26:11 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_3D90EE0C-8525-4FEC-97B4-6C98FDF0D6F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 11 May 2015 18:26:11 -0400 Message-Id: To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] corrected minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:26:16 -0000 --Apple-Mail=_3D90EE0C-8525-4FEC-97B4-6C98FDF0D6F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There were places in the minutes that noted incompleteness, but no = comments on the list. I reviewed the audio and filled in the noted = places. Since I had the audio and Meetecho open, I added audio times noted by my = player and the timestamps noted in the Meetecho chat room for the = beginning of each talk. Diff of old minutes to new minutes below. --Sandy P.S. Note: chat room during the meeting reported a delay in the audio = compared to video. This seems to be true in the audio archive as well. 0a1,7 > Audio times taken by observation from audio player. Meetecho = timestamps taken from Meetecho chat entries >=20 > audio URL: = http://www.ietf.org/audio/ietf92/ietf92-parisian-20150323-0900-am1.mp3 > Meetecho URL: = http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF92_S= IDR&chapter=3Dchapter_0 >=20 > audio archive time: 0:05:55 Meetecho timestamp (slide 7): 00:11:23 >=20 2a10,11 > audio archive time: 0:14:50 Meetecho timestamp: 00:14:48 >=20 18c27,29 < In the existing model you would need two signatures, right? --- > In the existing trust model you would need two = authorizations, right? > A: What we are mandating is that you must follow the 3779 = attributes > Andrei : Understand but do you require two signatures for a route = object, to follow the trust model? 21c32 < Are you suggesting we remove some of the constraints of the = existing system? --- > Are you suggesting we remove some of the constraints of the = existing system? That is, if RPSL sigs validate, but RPSS authorization = does not validate, will the system be changed so that the object can be = entered into the database? 29,30c40,45 < Sandy: In IRR databases that do not use RPSS authentication, we have = reports of people sneaking in objects for prefixes they were about to = hijack. < Is it possible to have=20 --- > Sandy: In IRR databases that do not use RPSS authentication, we have > reports of people sneaking in objects for prefixes they were about to > hijack. If you only have one signature on route objects, that would > continue to allow that behavior.=20 > A: You could have two attributes, one for each authorization. > Or one certificate that included both resources. 38a54,56 >=20 > audio archive time: 29:32 Meetecho time stamp: 00:30:32 >=20 46c64 < Sriram asked re: the detail of deferred validation visibility. Matt --- > Sriram asked re: the detail (eg per update) of deferred validation = visibility. Matt 50,51c68,69 < Ruediger: made a case for per-session policy (???). Wes George: in < the route policy, you might want to specify something about an AS in --- > Ruediger: made a case for per-session policy versus per-AS policy. = Wes George: in > the route policy, you might also want to specify policy about an AS in 55,56c73,78 < incredibly obvious, but you should probably say it anyway. [missed < Randy's point] --- > incredibly obvious, but you should probably say it anyway. =20 >=20 > Randy: Wes is confusing two things. Documents in other areas say that > you can specify for a peer or a set of prefixes, whether the markings > will be placed on the received path. That is different from deciding > to apply policy if the path includes an AS number. 60c82 < would be useful for debugging/packet capture. [Missed resolution] --- > would be useful for debugging/packet capture. Matt suggests: send = text. 63,65c85,117 < re: current code and AFI] Matt jumped to issue 7 re: mandating support < for multiprotocol extensions. No objection to requiring RFC4760 < support. --- > re: current code and AFI]=20 >=20 > John: I wonder if SAFI should also be there. Matt: This version of > BGPSEC only covers the AFI of IPv4 and IPv6, which means SAFI is not a > concern. Rob: There is a SAFI -- the only one allowed is the null = SAFI > - hash the non-existent byte. >=20 > Doug Montgomery: We briefly discussed to have BGPsec only use MP BGP - > so no multiple encodings of v4 and v6, and where it is getting the > hashes, so we could simplify things by saying all NLRI are carried in > the MP extensions. AFI is already in there. >=20 > Jeff Haas: One of the reasons why SAFI is a good thing to include is > that when it is time to support VPNs later we don't have to revise the > protocol to change the validation strategy of what we sign. (Matt > says: future proofing.) >=20 > Doug Montgomery: The fact that we have separated origin and path > validation means that we could at some point need to support other AFI > or SAFI, so a good idea to make it possible now, to use later. >=20 > Jeff Hass: Pretty much all code treats the non-MP case (IPv4 unicast) > as MP anyway. For common procedural stuff, instead of treating it as > null 0, treat it as the 1 SAFI, so even in then you are still > consistent even if it is in a different part of the packet. >=20 > Rob: John commented privately that there is no such thing as the null > SAFI in BGP. But there is in the RPKI. In RFC3779 - the SAFI is an > optional byte and in the RPKI as deployed that byte is required to be > absent. So you will have to deal with the fact that there is no SAFI. >=20 > Matt jumped to issue 7 re: mandating support for multiprotocol > extensions. No objection to requiring RFC4760 support. 79a132,133 > audio archive time 1:00:09 Meetecho timestamp: 01:04:02 >=20 95a150 > audio archive time: 1:10:30 Meetecho timestamp: 01:14:03 101c156,161 < Kent : We should have clear (not informational) documentation = somewhere as to exactly what the replying parties MUST do in order to = understand the security properties of the system --- > Note: slides used in the meeting were an old version: > https://www.ietf.org/proceedings/92/slides/slides-92-sidr-8.pdf >=20 > Kent : We should have clear (not informational) documentation > somewhere as to exactly what the replying parties MUST do in order to > understand the security properties of the system 104c164,170 < (Not to say that we should, but such relying party = documentation shouldn't hold up this rrdp specification) --- >=20 > (Not to say that we shouldn't, but such relying party = documentation shouldn't=20 > hold up this rrdp specification) >=20 > Tim B: would prefer to keep this document clean. Text should take = care not to restrict > relying parties more than necessary. Maybe, if wg agrees, we = could write a document > and share it with the wg. 111c177,178 < We don't trust withdrawl messages (if it hasn't been revoked = or removed from the manifest then we don't forget about it) --- > We don't trust withdrawal messages (if it hasn't been = revoked or removed from the=20 > manifest then we don't forget about it) 117c184,185 < We are happy to do HTTP since pervassive HTTPS is the world we = live in, as long as it doesn't break the protocol --- > We are happy to do HTTP since pervasive HTTPS is the world we = live in, as long as it=20 > doesn't break the protocol 119c187,189 < Jeff H: We don't care about privacy, but we should want integrety of = the transport --- > Jeff H: We don't care about privacy, but we should want integrity of = the transport session. Problem > is also withholding object or getting a stale object. Look at = lesson > of SMTP where bootstrapping stuff in a non-secure environment = and that being meddled with. 124c194 < If I can't trust that I am speaking to the right server, then I = can be DoS'ed (in nice ways) --- > If I can't trust that I am speaking to the right server, then I = can be DoS'ed (in "nice" ways) 131a202,203 > audio time: 1:44:25 Meetecho timestamp: 01:45:10 >=20 146a219,220 > audio archive time: 1:57:28 Meetecho timestamp: 01:57:24 >=20 164a239 > audio archive time: 2:15:40 Meetecho timestamp: 02:16:18=20 166c241 < **** Extemperaneous Presentation : Rutiger Volk --- > **** Extemporaneous Presentation : Rutiger Volk 185c260,261 < ... for splitting a PA aggregrate, first you inject the more = specific route, but before that you do the documenation (IRR and RPKI) --- > ... for splitting a PA aggregrate, first you inject the more = specific route, but before that=20 > you do the documentation (IRR and RPKI) 188c264,265 < Should have an AS zero ROA for the aggregate which will no longer be = advertised? --- > I extended the ROA, I created the route objects, I looked a bit ahead = and said I would=20 > eventually need a AS zero ROA for the aggregate that will no longer be = advertised. 194,195c271 <=20 < Terry M: Did you violate any procedure in RFC 6907 Section ??? --- > Terry M: Did you anything you did agree or disagree with RFC 6907 = Section 3? 205,206c281,283 < Randy: Two major problems with RPKI deployment < ... Most Egregious: Operators who issue a ROA for their 16 (and = clobber customers who have 24, but don't have ROAs) --- > Randy: Two major problems with RPKI deployment and then one more minor = thing. > ... Most Egregious: Operators who issue a ROA for their 16 (and = clobber customers who have 24,=20 > but don't have ROAs) 208d284 < ... Three: As RIPE and LACNIC scale up, we will eventually have = scaling issues with the transport mechanism =20 210,212c286,289 < Rob A: 3 of 5 RIRs have had trouble with this < Some implementors have chosen to have the EE cert expiration = very similar to the Manifest Next Update < ... This is dangerous if you are=20 --- > Rob A: (interjection) 3 of 5 RIRs have had trouble with this (the = manifest expiration problem) > Some implementors have chosen to have the EE cert expiration = very close to the Manifest Next Update time > ... This is dangerous if you are down for the weekend etc = (for RIRs, this makes all the region =20 > ... go poof) =20 215c292,296 < Jeff Haas: The SIDR group has a WIKI it would be easy for anyone with = an operational comment to toss it into the Wiki --- > (back to Randy): > ... Three: As RIPE and LACNIC scale up, we will eventually have = scaling issues with the transport mechanism =20 >=20 > Jeff Haas: The SIDR group has a WIKI it would be easy for anyone with = an operational comment to toss it=20 > into the Wiki 217c298 < Kavah: K-root address space has been signed in RPKI --- > Kavah: K-root anycast address space has been signed in RPKI --Apple-Mail=_3D90EE0C-8525-4FEC-97B4-6C98FDF0D6F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVUSyDAAoJEHplpQeet0IZDM0P/00HMTsIEzhf6N9+wArv18Bs ABTtXH/N9m8H64Mwmj/RvJFlh5Uv4zScjjhwtF9dqw2I/0iuPWSqo+4XUNQdOhHC aqCxMaSX4Ww7K350rkc+ulc/JwrCPho8Xz0IP2GlJ3nDK8fWwqx8hb/atOAGBd15 /opPC3bsrSSaTUKrbD4Tlt0/WkmPVif+mZt+thlDN1tMxT2Ii1jRTOHMDosT9JhZ sr2pqsAJoA7NJf6DBjas63Zc9T0p7lT6UOczDE76KaWJ1GMRIT8Loc7YEexnygMD dDCTfYuKz52Ov/4RSgNLsj3Z6s8xvxleZ+3p/G1oFs6uVAdjcIm34AjiG9+a95hF iFl0IWkg7UX/jUdzyHVpXkmEUxYKLcC+CdRXOGoVAyAX3es4E/SIKDy2eZOkevp8 YD7J7duMS6PtMGQCHZs+LynKoAxtg8eMHJJ7Hd+8YdHhoPLYMaksvVsxwJFPoGcg p2TBhWfDsDMa8LWnPCSkTrCbrzYAW0JhhqVt7nwlnfwWm2N0crGpmy38Tn2glWw2 5HWNEL2gWDvoi28EZPOfVD9YqovMU3x1EFg1FpTePPqinJbYvCN7cXO1ZFE5dTUB fdNVRlbutYwK8/wJWp/+vgv7crKDw7/ROZtq0eydnvp+q5K5tcKa4csaVasrqbB4 Qc42UpbVHReav059yDp3 =GHgi -----END PGP SIGNATURE----- --Apple-Mail=_3D90EE0C-8525-4FEC-97B4-6C98FDF0D6F3-- From nobody Thu May 14 22:10:14 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3717F1A8A3A; Thu, 14 May 2015 22:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgnZUW8kfjQO; Thu, 14 May 2015 22:10:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A82B1A8A64; Thu, 14 May 2015 22:10:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150515051010.31959.9930.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 22:10:10 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 05:10:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Authors : Geoff Huston Samuel Weiler George Michaelson Stephen Kent Filename : draft-ietf-sidr-rfc6490-bis-04.txt Pages : 9 Date : 2015-05-14 Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by adding support for multiple URIs in a TAL. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 15 12:22:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE41A87BE; Fri, 15 May 2015 12:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYF5JkSrFO3G; Fri, 15 May 2015 12:22:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC51A0387; Fri, 15 May 2015 12:22:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 12:22:15 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 19:22:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Authors : Geoff Huston George Michaelson Filename : draft-ietf-sidr-rfc6485bis-02.txt Pages : 7 Date : 2015-05-15 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format for the Resource Public Key Infrastructure subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the Relying Parties that verify these digital signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6485bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 20 13:04:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B28A1A8BAF for ; Wed, 20 May 2015 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdLR6-G9-zA2 for ; Wed, 20 May 2015 13:04:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220FA1A90AA for ; Wed, 20 May 2015 13:03:30 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:47601) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvADA-0008PV-Rg for sidr@ietf.org; Wed, 20 May 2015 16:03:28 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 8537D3FFD8 Message-ID: <555CE890.1090802@bbn.com> Date: Wed, 20 May 2015 16:03:28 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> In-Reply-To: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:04:03 -0000 Hi all, I did a careful review of this draft and sent detailed comments to the authors off list. Here is a summary of my comments for everyone's reference: Important issues: * the reference to RFC6488 in the introduction was accidentally changed to RFC2119 * section 8 is incorrect -- sha256WithRSAEncryption does not violate the CMS RFCs (implementations just choose to use rsaEncryption instead, which has the same meaning in this context) * the OID and meaning of rsaEncryption is not defined in this document, and there is no normative reference to a definition Moderate issues: * section 2 is confusing (alternative wording sent to authors) * errata not incorporated (though their status is still "Reported"...) * certification requests aren't mentioned everywhere they should be Minor issues: * many of the edits made by the RFC Editor are missing * at the beginning of section 2, the reference to RFC4055 Section 5 should be RFC3447 Section 8.2 Nice-to-haves: * replace "signed object" with "CMS signed object" to avoid ambiguity * add a Table of Contents * include informative references in the introduction * cite the algorithm agility RFC in section 5 -Richard On 2015-05-15 15:22, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure > Authors : Geoff Huston > George Michaelson > Filename : draft-ietf-sidr-rfc6485bis-02.txt > Pages : 7 > Date : 2015-05-15 > > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format for > the Resource Public Key Infrastructure subscribers that generate > digital signatures on certificates, Certificate Revocation Lists, and > signed objects as well as for the Relying Parties that verify these > digital signatures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6485bis-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu May 21 14:08:21 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AA41A904F for ; Thu, 21 May 2015 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmE2fz66AGUi for ; Thu, 21 May 2015 14:08:18 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CAA1A904E for ; Thu, 21 May 2015 14:08:18 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id C460B28B0043; Thu, 21 May 2015 17:08:16 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id A7B081F8035; Thu, 21 May 2015 17:08:16 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C2F05270-62EA-4E8B-9A1B-6C096DDCEA7F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <555CE890.1090802@bbn.com> Date: Thu, 21 May 2015 17:08:15 -0400 Message-Id: References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:08:20 -0000 --Apple-Mail=_C2F05270-62EA-4E8B-9A1B-6C096DDCEA7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You are missing some history here. When this issue arose, the agreement = was that the bis would address the OID only, and changes and comments = were to be only those necessary to correct that problem. (I myself participated in that agreement and then exceeded the = restriction in my own comments! You, who were not in the working group = at the time, have much less reason to know.) --Sandy, speaking as working group chair On May 20, 2015, at 4:03 PM, Richard Hansen wrote: > Hi all, >=20 > I did a careful review of this draft and sent detailed comments to the > authors off list. Here is a summary of my comments for everyone's > reference: >=20 > Important issues: >=20 > * the reference to RFC6488 in the introduction was accidentally > changed to RFC2119 > * section 8 is incorrect -- sha256WithRSAEncryption does not > violate the CMS RFCs (implementations just choose to use > rsaEncryption instead, which has the same meaning in this > context) > * the OID and meaning of rsaEncryption is not defined in this > document, and there is no normative reference to a definition >=20 > Moderate issues: >=20 > * section 2 is confusing (alternative wording sent to authors) > * errata not incorporated (though their status is still = "Reported"...) > * certification requests aren't mentioned everywhere they should be >=20 > Minor issues: >=20 > * many of the edits made by the RFC Editor are missing > * at the beginning of section 2, the reference to RFC4055 Section 5 > should be RFC3447 Section 8.2 >=20 > Nice-to-haves: >=20 > * replace "signed object" with "CMS signed object" to avoid ambiguity > * add a Table of Contents > * include informative references in the introduction > * cite the algorithm agility RFC in section 5 >=20 > -Richard >=20 >=20 > On 2015-05-15 15:22, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : The Profile for Algorithms and Key Sizes for = use in the Resource Public Key Infrastructure >> Authors : Geoff Huston >> George Michaelson >> Filename : draft-ietf-sidr-rfc6485bis-02.txt >> Pages : 7 >> Date : 2015-05-15 >>=20 >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format = for >> the Resource Public Key Infrastructure subscribers that generate >> digital signatures on certificates, Certificate Revocation Lists, = and >> signed objects as well as for the Relying Parties that verify these >> digital signatures. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-02 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6485bis-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_C2F05270-62EA-4E8B-9A1B-6C096DDCEA7F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVXkk/AAoJEHplpQeet0IZvdIP/0o/HLLlRxck95hW3LaPq7Z2 CQKm14ODodmy7J+z6xKku3yUJNDOH9vQShllOtzuP+mtLL0g9oY4GYT8csqhhmi6 0O/iBMJZ/eVtx5S9/a4jb+gc9h8qKwIkdI/WAsxIbqs5NXXLAUbK+U7Q/tVyBKp+ Ej5sL9t91st6g3HXvuImoqIi+YVXx2qjyySgKJlonfA8GoRHd4AU2toMssAd4dib TVMGgme7bUPgqX19WciHTbyTCNKLwuFOwX/jkU6pm+nmJb/W5WtsxxdVYHNnPSjZ gO0btoKlAFlX+UtsgEgDCe9o8qKwz124AUtaHPKdfEh/Vl3OO5N8BW/YTC3vkuaf NPnutkfg5iE0CTBf17w7kNGZSst8iDHZpBkLBm78leFxmT4pHSoc+rvyniBkCwV4 M5uw62f+RXdEJuDfXkkAsRi2rxPDXvZtKyYDPshTKZrbA+V4jbb76GZ+iTClpA5G TktCbKld1i+6KfzJj+GmgfiyBDwJwOReXgHCg7d21H5Jsfmu/7L6buIfaJmFyYIA tuCV7FPnWd/tLH6UDZbxGzfQsBAjVSSJgZgw5YfmIYQayRQ4puaW2I5rVjayz0iL 0PmnyTYB7pd5ml3kbLqD7Q8GiZxd99U6tiRQIQNNqYu/SCGQjeHxPPZRDGLGZb7S fIF/yJOkJHJ1BgBdegph =jU9+ -----END PGP SIGNATURE----- --Apple-Mail=_C2F05270-62EA-4E8B-9A1B-6C096DDCEA7F-- From nobody Thu May 21 14:09:11 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA711A904E for ; Thu, 21 May 2015 14:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw9R35YTCPNF for ; Thu, 21 May 2015 14:09:00 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF39D1A904F for ; Thu, 21 May 2015 14:09:00 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 12B3128B0043; Thu, 21 May 2015 17:09:00 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 0CEEC1F8035; Thu, 21 May 2015 17:09:00 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6CFB7CE4-AE99-4ADD-9F0A-9AD498669489"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <555CE890.1090802@bbn.com> Date: Thu, 21 May 2015 17:08:59 -0400 Message-Id: <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:09:06 -0000 --Apple-Mail=_6CFB7CE4-AE99-4ADD-9F0A-9AD498669489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 20, 2015, at 4:03 PM, Richard Hansen wrote: > Hi all, >=20 > I did a careful review of this draft and sent detailed comments to the > authors off list. Here is a summary of my comments for everyone's > reference: >=20 > Important issues: >=20 > * the reference to RFC6488 in the introduction was accidentally > changed to RFC2119 > * section 8 is incorrect -- sha256WithRSAEncryption does not > violate the CMS RFCs (implementations just choose to use > rsaEncryption instead, which has the same meaning in this > context) You might want to review the message on the list: https://www.ietf.org/mail-archive/web/sidr/current/msg04813.html that covers the whole CMS mandatory-to-implement requirement, the = implementations, and the whole tangled story of the document chain. =20 [That's Rob Austein, who also acknowledges Andrew Chi, David Mandelberg, = and Russ Housley assisting in untangling the tangled web of references.] Perhaps you are concerned mostly about the terms being used? But the = rfc6485bis document does not say "violate" and I believe that what it = says agrees with the message above. If you don't think so, you should = say why. > * the OID and meaning of rsaEncryption is not defined in this > document, and there is no normative reference to a definition This is not the right place to define the OID for rsaEncryption. It is = found in 3370, which 5754 (one of the references) updates and = normatively references. =20 >=20 > Moderate issues: >=20 > * section 2 is confusing (alternative wording sent to authors) > * errata not incorporated (though their status is still "Reported"=85) Those that are still shown as "Reported" have not yet been reviewed. As = Sean said, it is possible for an errata to be rejected. The description of the errata process is found at = https://www.ietf.org/iesg/statement/errata-processing.html. --Sandy, speaking as regular ol' member > * certification requests aren't mentioned everywhere they should be >=20 > Minor issues: >=20 > * many of the edits made by the RFC Editor are missing > * at the beginning of section 2, the reference to RFC4055 Section 5 > should be RFC3447 Section 8.2 >=20 > Nice-to-haves: >=20 > * replace "signed object" with "CMS signed object" to avoid ambiguity > * add a Table of Contents > * include informative references in the introduction > * cite the algorithm agility RFC in section 5 >=20 > -Richard >=20 >=20 > On 2015-05-15 15:22, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : The Profile for Algorithms and Key Sizes for = use in the Resource Public Key Infrastructure >> Authors : Geoff Huston >> George Michaelson >> Filename : draft-ietf-sidr-rfc6485bis-02.txt >> Pages : 7 >> Date : 2015-05-15 >>=20 >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format = for >> the Resource Public Key Infrastructure subscribers that generate >> digital signatures on certificates, Certificate Revocation Lists, = and >> signed objects as well as for the Relying Parties that verify these >> digital signatures. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-02 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6485bis-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_6CFB7CE4-AE99-4ADD-9F0A-9AD498669489 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVXklrAAoJEHplpQeet0IZllYP/2GgupQcheR3a5aIb1boPOoh IcHr3Vc8EIaJAQ9d7DKNCD5Az6ApTl2gzMteQsMDHeyIsGeOgXRPR6qqKdrTSJVT GQAMV4Cv9N5eRAWJ6feULNlA0f8pT/0SP1abxgVhUZpNEKVH2xo+sYxgleK5/kBZ e+wAjgbQa+dvHEsfAucF6aa7Cqy4ujIBLNq5390rciOxBP6wm3lugvCbyxQmiICB kAQcKV4CJgzepH81qZ8G+kPcdOY5qoXHNIPQlGCVQRPcgFt0u1TvLeTdXmlGyEs3 Q4EeSsjUYnpA2mc+fJgQpuxpn4ifxhZ1vca7IQHicz4V1V4/GyddIyO7iL9BfC49 FY/mEzafIT3/beV42DSJqJy1XW2GrYRCHtbTGiLOy+lruxAO5wlxkUa2b+/iGZ+J 1aUn1noi8GNmdRxiGr1i1wu1zKXZfw/QEvIGOZQN/FCHo5gwvM3bWtPqQ6+8fK5G +jdAheFlH2n5wDbijJOYtYl0J/IhVBfnMTTCgquGK2aOScQAHQms+VOk3dC3Wz/b s/vsfy1ndFCwoepdf1REHXFuPCp9RPfzGeGNmkUeAlBFKV32hN0hwA6qNa8dXsuY HtLdYfFh7XaWqu6VrjeyTKvFBxSYkAnrAR8YDg6lUeu/7nF8cP3kN6VqvcIAs4q9 SpnDcE8lfJxGGWvr8PZt =pw2U -----END PGP SIGNATURE----- --Apple-Mail=_6CFB7CE4-AE99-4ADD-9F0A-9AD498669489-- From nobody Thu May 21 14:16:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2121A9074 for ; Thu, 21 May 2015 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ypvrDSGRbvI for ; Thu, 21 May 2015 14:16:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3121A906B for ; Thu, 21 May 2015 14:16:07 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:48074) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvXoz-000MI8-6t; Thu, 21 May 2015 17:16:05 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id F00743FFD8 Message-ID: <555E4B0E.8030505@bbn.com> Date: Thu, 21 May 2015 17:15:58 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sandra Murphy References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="38VudkgXLe4oOWSemetHX07jhuRTAosFH" Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:16:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --38VudkgXLe4oOWSemetHX07jhuRTAosFH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-05-21 17:08, Sandra Murphy wrote: > You are missing some history here. When this issue arose, the > agreement was that the bis would address the OID only, and changes > and comments were to be only those necessary to correct that > problem. OK. To keep the scope of changes limited to the OID issue, ignore the following from my list of issues: Moderate: * errata not incorporated (though their status is still "Reported"...) * certification requests aren't mentioned everywhere they should be Minor: * at the beginning of section 2, the reference to RFC4055 Section 5 should be RFC3447 Section 8.2 Nice-to-haves: * replace "signed object" with "CMS signed object" to avoid ambiguity * add a Table of Contents * include informative references in the introduction * cite the algorithm agility RFC in section 5 -Richard >=20 > (I myself participated in that agreement and then exceeded the > restriction in my own comments! You, who were not in the working > group at the time, have much less reason to know.) >=20 > --Sandy, speaking as working group chair >=20 > On May 20, 2015, at 4:03 PM, Richard Hansen wrote: >=20 >> Hi all, >>=20 >> I did a careful review of this draft and sent detailed comments to >> the authors off list. Here is a summary of my comments for >> everyone's reference: >>=20 >> Important issues: >>=20 >> * the reference to RFC6488 in the introduction was accidentally=20 >> changed to RFC2119 * section 8 is incorrect -- >> sha256WithRSAEncryption does not violate the CMS RFCs >> (implementations just choose to use rsaEncryption instead, which >> has the same meaning in this context) * the OID and meaning of >> rsaEncryption is not defined in this document, and there is no >> normative reference to a definition >>=20 >> Moderate issues: >>=20 >> * section 2 is confusing (alternative wording sent to authors) * >> errata not incorporated (though their status is still >> "Reported"...) * certification requests aren't mentioned everywhere >> they should be >>=20 >> Minor issues: >>=20 >> * many of the edits made by the RFC Editor are missing * at the >> beginning of section 2, the reference to RFC4055 Section 5 should >> be RFC3447 Section 8.2 >>=20 >> Nice-to-haves: >>=20 >> * replace "signed object" with "CMS signed object" to avoid >> ambiguity * add a Table of Contents * include informative >> references in the introduction * cite the algorithm agility RFC in >> section 5 >>=20 >> -Richard >>=20 >>=20 >> On 2015-05-15 15:22, internet-drafts@ietf.org wrote: >>>=20 >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> Secure Inter-Domain Routing Working Group of the IETF. >>>=20 >>> Title : The Profile for Algorithms and Key Sizes for >>> use in the Resource Public Key Infrastructure Authors : >>> Geoff Huston George Michaelson Filename : >>> draft-ietf-sidr-rfc6485bis-02.txt Pages : 7 Date >>> : 2015-05-15 >>>=20 >>> Abstract: This document specifies the algorithms, algorithms' >>> parameters, asymmetric key formats, asymmetric key size and >>> signature format for the Resource Public Key Infrastructure >>> subscribers that generate digital signatures on certificates, >>> Certificate Revocation Lists, and signed objects as well as for >>> the Relying Parties that verify these digital signatures. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is:=20 >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >>>=20 >>> There's also a htmlized version available at:=20 >>> https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-02 >>>=20 >>> A diff from the previous version is available at:=20 >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6485bis-02 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at:=20 >>> ftp://ftp.ietf.org/internet-drafts/ --38VudkgXLe4oOWSemetHX07jhuRTAosFH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVeSxQACgkQMs/lq+4xKKK+0ACeLMCZ3Iv2i0yMkX9U3gyHXbpN qvAAoLPnFfaOOU/+GoLlPp3jDIEoM32r =0Qb4 -----END PGP SIGNATURE----- --38VudkgXLe4oOWSemetHX07jhuRTAosFH-- From nobody Thu May 21 15:22:49 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4772E1A90EE; Thu, 21 May 2015 15:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFfV1znIMG72; Thu, 21 May 2015 15:22:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B96721A90E5; Thu, 21 May 2015 15:22:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BB4FE18046A; Thu, 21 May 2015 15:20:54 -0700 (PDT) To: sandy@tislabs.com, gih@apnic.net X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150521222054.BB4FE18046A@rfc-editor.org> Date: Thu, 21 May 2015 15:20:54 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, sidr@ietf.org Subject: [sidr] [Errata Verified] RFC6485 (4339) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:22:43 -0000 The following errata report has been verified for RFC6485, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6485&eid=4339 -------------------------------------- Status: Verified Type: Technical Reported by: Sandra Murphy Date Reported: 2015-04-20 Verified by: Alvaro Retana (IESG) Section: 2. Original Text ------------- In a certification request, the OID appears in the PKCS #10 signatureAlgorithm field [RFC2986] or in the Certificate Request Message Format (CRMF) POPOSigningKey signature field [RFC4211]. Corrected Text -------------- In a certification request, the OID appears in the PKCS #10 signatureAlgorithm field [RFC2986] or in the Certificate Request Message Format (CRMF) POPOSigningKey algorithmIdentifier field [RFC4211]. Notes ----- This is technically a technical change, as it would technically affect implementation, but I believe in fact it is just a typo. Only a very inexperienced implementor would put the RFC6485 algorithm OID in the signature field of the POPOSigningKey. This problem was noted in a message to the sidr list https://www.ietf.org/mail-archive/web/sidr/current/msg06587.html and supported by another message https://www.ietf.org/mail-archive/web/sidr/current/msg06649.html At noted in the message to the sidr list, RFC4211 says that the POPOSigningKey is: POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING } The OID mentioned in the RFC6485 text is for the algorithm identifier and so should appear in the algorithmIdentifier field, not the signature field. -------------------------------------- RFC6485 (draft-ietf-sidr-rpki-algs-05) -------------------------------------- Title : The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) Publication Date : February 2012 Author(s) : G. Huston Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu May 21 15:29:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5881A8784; Thu, 21 May 2015 15:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmlVAadW4un8; Thu, 21 May 2015 15:29:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 314F11A0191; Thu, 21 May 2015 15:29:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2E824180208; Thu, 21 May 2015 15:27:15 -0700 (PDT) To: rhansen@bbn.com, gih@apnic.net X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150521222715.2E824180208@rfc-editor.org> Date: Thu, 21 May 2015 15:27:15 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, sidr@ietf.org Subject: [sidr] [Errata Held for Document Update] RFC6485 (4340) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:29:03 -0000 The following errata report has been held for document update for RFC6485, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6485&eid=4340 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Richard Hansen Date Reported: 2015-04-20 Held by: Alvaro Retana (IESG) Section: 1 Original Text ------------- the SIDR Architecture [RFC6480], Corrected Text -------------- the RPKI Architecture [RFC6480], Notes ----- Neither "SIDR" nor "Secure Inter-Domain Routing" is mentioned in RFC6480. RFC6480 is about the design of the RPKI, so "RPKI Architecture" seems like a more appropriate fit. -------------------------------------- RFC6485 (draft-ietf-sidr-rpki-algs-05) -------------------------------------- Title : The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) Publication Date : February 2012 Author(s) : G. Huston Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu May 21 15:39:34 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5B61A87DF for ; Thu, 21 May 2015 15:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhqD3DA-H5LA for ; Thu, 21 May 2015 15:39:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673881A90DD for ; Thu, 21 May 2015 15:38:04 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:48094) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvZ6J-000NwZ-4C; Thu, 21 May 2015 18:38:03 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id CA4173FFFD Message-ID: <555E5E4A.5080303@bbn.com> Date: Thu, 21 May 2015 18:38:02 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sandra Murphy References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> In-Reply-To: <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L7wAxma3UnQ6O1rPa56pQ09eFGRj91HT2" Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:39:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L7wAxma3UnQ6O1rPa56pQ09eFGRj91HT2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-05-21 17:08, Sandra Murphy wrote: > On May 20, 2015, at 4:03 PM, Richard Hansen wrote: >> * section 8 is incorrect -- sha256WithRSAEncryption does not >> violate the CMS RFCs (implementations just choose to use >> rsaEncryption instead, which has the same meaning in this >> context) >=20 [...] >=20 > Perhaps you are concerned mostly about the terms being used? But the > rfc6485bis document does not say "violate" and I believe that what it > says agrees with the message above. If you don't think so, you > should say why. This draft's Section 8 says: [...] A closer reading of [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field must support use of the rsaEncryption OID for full conformance with the CMS specifications, and the normative references in [RFC6485] inherited this requirement. The phrase "the CMS SignerInfo field must support use of the rsaEncryption OID" doesn't make much sense to me -- how can an OID field not support an OID? I'm not 100% sure what is meant here, but the next paragraph provides a hint: [...] By conforming to the CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects are less likely to be rejected as non-conformant with the CMS standards. To me, this sentence and the one above are claiming that the CMS RFCs say that the SignerInfo signatureAlgorithm field MUST contain rsaEncryption, and that we are non-conformant (violating the spec) by using sha256WithRSAEncryption. Neither is true. The CMS RFCs say that CMS signed object RP implementations MUST support the rsaEncryption algorithm. This is not the same as requiring the field to contain rsaEncryption. It's perfectly OK to put sha256WithRSAEncryption in that field. It's also OK for us to burden CMS RPs with an additional requirement to support sha256WithRSAEncryption when validating RPKI objects (which RFC6485 and this bis both do). RFC6485 burdened INR holders with the requirement to use sha256WithRSAEncryption when *producing* CMS signed objects for the RPKI, and if I understand the history correctly, this is where things got tricky. From a CMS RFC conformance perspective it's perfectly OK for RFC6485 to require RPKI CMS object producers to use sha256WithRSAEncryption, but third party crypto libs didn't make it easy for implementations to conform. Thus, implementations used rsaEncryption instead. Rather than change implementations (difficult), we decided to unburden the CMS producers and change the spec (easy). I provided Geoff and George with alternative wording for Section 8 that I think is more correct, but of course they may disagree. BTW, you may find this thread relevant: http://thread.gmane.org/gmane.ietf.smime/7053 >> * the OID and meaning of rsaEncryption is not defined in this >> document, and there is no normative reference to a definition >=20 > This is not the right place to define the OID for rsaEncryption. I completely agree. All I meant here is that we need to either define it or cite something that does. I suggested to Geoff and George to simply add "[RFC3370]" after rsaEncryption to fix this. > It is found in 3370, which 5754 (one of the references) updates and > normatively references. I don't think that is sufficient in this case. There are multiple RFCs that this document directly and indirectly references that define an algorithm identifier named rsaEncryption. I believe they all have the same OID value, but some of them give slightly different semantics. Thus, I think it's important to make it clear which definition of rsaEncryption is intended. For example, RFC3370 (for CMS) says that rsaEncryption is either a key type identifier or a signature algorithm identifier, while RFC3279 (for PKIX) says that it's only a key type identifier and thus not suitable for identifying signature algorithms in a PKIX context (you must use xxxWithRSAEncryption instead to specify the digest). There may be more significant semantic differences in other RFCs; I haven't done an exhaustive search. >> * errata not incorporated (though their status is still "Reported"...= ) >=20 > Those that are still shown as "Reported" have not yet been reviewed. > As Sean said, it is possible for an errata to be rejected. >=20 > The description of the errata process is found at > https://www.ietf.org/iesg/statement/errata-processing.html. Understood -- the parenthetical was meant to be a disclaimer acknowledging that they might get rejected. However, if this bis is published and the errata are then set to verified/HFDU, then what do we do? Do we somehow move the errata over to the new RFC? Do we resubmit them and go through the process again? It seems like we'd save ourselves a lot of trouble by simply incorporating them now, especially since there's no controversy over the changes (that I know of). -Richard --L7wAxma3UnQ6O1rPa56pQ09eFGRj91HT2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVeXkoACgkQMs/lq+4xKKIhFACgqMMoR+LMRntL0zvypjSgfJ67 WuMAoMWloo52Qrt1gXTTpbVXnmrYfXxE =l9sb -----END PGP SIGNATURE----- --L7wAxma3UnQ6O1rPa56pQ09eFGRj91HT2-- From nobody Fri May 22 07:55:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210FF1A1A1B for ; Fri, 22 May 2015 07:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHpYqt43H9-8 for ; Fri, 22 May 2015 07:55:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2771A0E10 for ; Fri, 22 May 2015 07:55:47 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:48049) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvoMT-0002PZ-Um for sidr@ietf.org; Fri, 22 May 2015 10:55:46 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 24B423FFFD Message-ID: <555F436F.3080003@bbn.com> Date: Fri, 22 May 2015 10:55:43 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: sidr wg list Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:55:49 -0000 Hi all, A while back Sean Turner raised the idea of switching to SHA-256 for the Subject Key Identifier while discussing rfc6487bis (see ). I see a couple of reasons to do this: * If/when additional weaknesses are found in SHA-1, 3rd party cryptographic libraries that implement SHA-1 may become hard to find. * If/when a serious weakness is found in SHA-1, someone might be able to exploit the weakness to attack some aspect of RPKI/BGPsec. Thinking about the latter, I believe there is a not-entirely-implausible attack that might justify a change: 1. An attacker uses a weakness in SHA-1 to generate a large number of BGPsec router certificates for an AS, where each certificate has a different key but the same SKI. 2. The attacker uses one of those certificates to generate a signature segment in the BGPsec_Path attribute, and sends the BGPsec Update message to a peer. 3. The peer starts the process of validating the signature segment generated by the attacker. Due to the numerous keys with the same SKI, the peer is forced to test each of the attacker's keys one by one until a match is found. This could take a considerable amount of time. 4. While it is validating the signature, the peer processes all Update messages as if they were unsigned because there is not enough CPU available at the moment. The attacker has succeeded in (temporarily) disabling BGPsec. One way to block the above attack is to use a stronger hash function (e.g., SHA-256) for the SKI. Unfortunately, because the SKI extension doesn't have an algorithm identifier field, there's no way to switch without a flag day. We could make a proactive change now while deployment is low, but it would still be unpleasant. An alternative idea suggested by Matt Lepinski is to prohibit router certificate SKI collisions within an AS if the keys differ. In other words, if there are two valid BGPsec router certs in the same AS with different keys but the same SKI, then RPs MUST mark them both as invalid. Thanks to the RFC3779 checks, it would not be possible for someone in a different AS to invalidate your certs even if a weakness in SHA-1 was discovered. So I propose we add something like the following to the end of Section 3 in draft-ietf-sidr-bgpsec-pki-profiles: o To prevent denial-of-service attacks against RPs, Subject Key Identifier collisions within an AS are not permitted. Any BGPsec Router Certificate that: * references the same AS number in the Autonomous System Identifier Delegation extension, * has a different key, and * has the same value in the Subject Key Identifier extension as another otherwise valid certificate MUST NOT be considered valid. We may also want to add something to rfc6487bis to invalidate a certificate if its SKI matches an ancestor (and the key differs), though I can't think of a way to take advantage of such a collision at the momen= t. Thoughts? Thanks, Richard From nobody Fri May 22 15:28:36 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE0D1A897E for ; Fri, 22 May 2015 15:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saDWCsGqYyM3 for ; Fri, 22 May 2015 15:28:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AFE1A891B for ; Fri, 22 May 2015 15:28:03 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:48143) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvvQ3-0006gO-RP; Fri, 22 May 2015 18:27:55 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 95BC140058 Message-ID: <555FAD6B.7030902@bbn.com> Date: Fri, 22 May 2015 18:27:55 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gih@apnic.net, weiler@tislabs.com, ggm@apnic.net, Stephen Kent References: <20150515051010.31959.9930.idtracker@ietfa.amsl.com> In-Reply-To: <20150515051010.31959.9930.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 22:28:34 -0000 Hi Geoff, Sam, George, and Steve, I spotted a bug in this draft: Section 2.1 refers to Base64 encoding, defined in RFC4648 Section 4. RFC4648 Section 3.1 says: Implementations MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs base encoders to add line feeds after a specific number of characters. Section 2.1 doesn't say anything about adding newlines to the Base64 string, yet the example in Section 2.3 contains embedded newlines every 57 characters. Rather than fix the example in Section 2.3 to conform to the current Section 2.1, I think it would be better to permit newlines in the Base64 data: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]). To avoid long lines, a or line break MAY be inserted into the Base64 encoded string every 40 or more characters. The choice of 40 is arbitrary; I just didn't want an implementation to be ridiculous and add a newline after only one or a few characters. I wouldn't mind changing it to "MUST be inserted every 40 to 76 characters" to make it possible to write a parser with fixed-length line buffers. (I also spotted a few typos, sent off-list.) -Richard On 2015-05-15 01:10, internet-drafts@ietf.org wrote: > > 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 : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator > Authors : Geoff Huston > Samuel Weiler > George Michaelson > Stephen Kent > Filename : draft-ietf-sidr-rfc6490-bis-04.txt > Pages : 9 > Date : 2015-05-14 > > Abstract: > This document defines a Trust Anchor Locator (TAL) for the Resource > Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by > adding support for multiple URIs in a TAL. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Thu May 28 14:34:45 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF631A8AE6 for ; Thu, 28 May 2015 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQqF22AzeUpV for ; Thu, 28 May 2015 14:34:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF541A1B88 for ; Thu, 28 May 2015 14:34:41 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49445) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Yy5Rg-000DE9-Fh; Thu, 28 May 2015 17:34:32 -0400 Message-ID: <556789E8.8080907@bbn.com> Date: Thu, 28 May 2015 17:34:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Hansen , gih@apnic.net, weiler@tislabs.com, ggm@apnic.net References: <20150515051010.31959.9930.idtracker@ietfa.amsl.com> <555FAD6B.7030902@bbn.com> In-Reply-To: <555FAD6B.7030902@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 21:34:43 -0000 Richard, Sorry to be late replying to your message, but I just returned from a vacation trip. I think we can do one of two things to address the problem you correctly identified: 1- either say that the example in the doc has been formatted for the RFC, and that no LFs are permitted 2- adopt your text to explicitly override the "no NL" rule in 4648. Steve > Hi Geoff, Sam, George, and Steve, > > I spotted a bug in this draft: Section 2.1 refers to Base64 encoding, > defined in RFC4648 Section 4. RFC4648 Section 3.1 says: > > Implementations MUST NOT add line feeds to base-encoded data unless > the specification referring to this document explicitly directs base > encoders to add line feeds after a specific number of characters. > > Section 2.1 doesn't say anything about adding newlines to the Base64 > string, yet the example in Section 2.3 contains embedded newlines every > 57 characters. > > Rather than fix the example in Section 2.3 to conform to the current > Section 2.1, I think it would be better to permit newlines in the Base64 > data: > > 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], > encoded in Base64 (see Section 4 of [RFC4648]). To avoid > long lines, a or line break MAY be inserted into > the Base64 encoded string every 40 or more characters. > > The choice of 40 is arbitrary; I just didn't want an implementation to > be ridiculous and add a newline after only one or a few characters. > > I wouldn't mind changing it to "MUST be inserted every 40 to 76 > characters" to make it possible to write a parser with fixed-length line > buffers. > > (I also spotted a few typos, sent off-list.) > > -Richard > > > On 2015-05-15 01:10, internet-drafts@ietf.org wrote: >> 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 : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator >> Authors : Geoff Huston >> Samuel Weiler >> George Michaelson >> Stephen Kent >> Filename : draft-ietf-sidr-rfc6490-bis-04.txt >> Pages : 9 >> Date : 2015-05-14 >> >> Abstract: >> This document defines a Trust Anchor Locator (TAL) for the Resource >> Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by >> adding support for multiple URIs in a TAL. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-04 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > From nobody Sun May 31 12:07:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECCA1A88FA for ; Sun, 31 May 2015 12:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5M78UfS2z-2 for ; Sun, 31 May 2015 12:07:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08501A8905 for ; Sun, 31 May 2015 12:07:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Yz8ZX-0001V8-KX for sidr@ietf.org; Sun, 31 May 2015 19:07:00 +0000 Resent-Message-Id: Resent-From: Randy Bush Resent-Date: Sun, 31 May 2015 12:06:58 -0700 Resent-To: sidr@ietf.org Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1YypvS-0007Lm-RU for randy@ran.psg.com; Sat, 30 May 2015 23:12:22 +0000 Received: from mail.ietf.org ([2001:1900:3001:11::2c]) by psg.com with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YypvM-000DMA-T9 for randy@psg.com; Sat, 30 May 2015 23:12:16 +0000 Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A021E1A89F9; Sat, 30 May 2015 16:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AedjSV3nhYKI; Sat, 30 May 2015 16:12:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 303A71A89FD; Sat, 30 May 2015 16:12:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Rob Austein" , "Geoff Huston" , "Randy Bush" , "George Michaelson" , "Geoff Huston" , "Rob Austein" , "George G. Michaelson" , "Randy Bush" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> Date: Sat, 30 May 2015 16:12:11 -0700 Archived-At: Subject: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 19:07:02 -0000 A new version of I-D, draft-ymbk-sidr-transfer-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-sidr-transfer Revision: 00 Title: Resource Transfer in the Resource Public Key Infrastructure Document date: 2015-05-30 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-ymbk-sidr-transfer-00.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-sidr-transfer/ Htmlized: https://tools.ietf.org/html/draft-ymbk-sidr-transfer-00 Abstract: Transfer within the RPKI of actual address space and/or autonomous system number resources between two Internet registries (ISPs, RIRs, NIRs, etc.) is reasonably achievable for most useful operational needs. In this paper, we describe, at a high level, how this may be accomplished. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat