Subject: Re: [sidr] RPSLSIG adoption?

From: Geoff Huston <[email-masked]>
Date: Tue, 2 Dec 2008 11:00:07 +1100

On 19/11/2008, at 2:40 AM, Robert Kisteleki wrote:

> Hi,
>
> After my (rushed) presentation yesterday I'd like to ask if there  
> are people in the WG who think that this idea is worth pursuing and  
> should it be a WG item?
>
> http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt

WG Co-Chair hat ON

Thank you for your presentation to the WG at the last IETF meeting.

After asking the WG for their views on this question, I have reviewed  
the WG email on this question, the SIDR charter, and consulted with  
the relevant Routing AD on the charter issue, and as a result I am in  
a position to conclude that I have observed a rough consensus on the  
part of the Working Group in favour of adoption of this document as a  
WG item.

I would like to request that you edit your draft to reflect this,  
(draft-ietf-sidr-rpsl-sig) and submit this draft as a WG document.

Kind regards,

    Geoff Huston
    co-char SIDR WG.

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Dec 2008 15:18:31 -0500

At 3:39 PM +0100 11/27/08, Robert Kisteleki wrote:
>Stephen Kent wrote:
>>However, I worry that we need to tightly restrict which RPSL data 
>>can be validated using an RPKI cert. My concern is that it would be 
>>easy for folks to misinterpret the extent of what an RPLI cert 
>>attests to, and thus accord signed RPSL data more trust than it 
>>deserves. I also worry that using RPKI certs for this purpose might 
>>cause folks to want to have Subject names be meaningful, not 
>>arbitrary, as now required by our specs. So, if Robert is 
>>comfortable with imposing these sorts of constraints, I think it 
>>appropriate to make this a work item.
>
>Section (2) of the draft says:
>
>"2.  Meaning of a signature
>
>    By signing an RPSL object, the signer of the object expresses that:
>    o  they have the right to use the resource that the object refers to
>       (ie. found as the primary key or in some other field of the
>       object);
>    o ..."
>
>So in fact I already restrict the usage to only those type of 
>objects that have something to to with actual number resources (ie. 
>this excludes person objects). I'd be less comfortable to state *in 
>this document* that the certificate subject names should not be 
>meaningful; I'd defer that to the higher level documents such as the 
>certificate profile and architecture documents. However, since this 
>is only redundancy, not a new requirement, I'm not specifically 
>against this.
>
>Robert

Robert,

Thanks for the clarification., but I still have some serious concerns 
that I think need to be addressed as we progress this as a WG item.

I looked at your document and I see that section 5 is  a "Minimum set 
of Signed Attributes." To try to prevent the problem I cited, it 
really needs a definitive list of the objects and attributes that MAY 
be signed, with a prohibition on signing any other 
objects/attributes.  This is the opposite of what your text says, as 
it allows the signer to include whatever other attributes the signer 
wishes.

The name of an AS is NOT something that can be validated using the 
RPKI, and this needs to made clear to folks using this mechanism. The 
same is true for net name, org, country and status. The simplest 
thing to do would be to exclude these as signed attributes. I am not 
very familiar with the attributes you listed for the four object 
types, but I suspect that a more of them will fall into this category.

Also, for each of these objects/attributes, you need to describe what 
constitutes validation based on an appropriate cert or ROA, i.e., 
what checks MUST be performed by the RP to ensure that the signed 
object/attributes are consistent with the ROKI objects used to verify 
the signature.

Steve

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 03 Dec 2008 09:52:30 +0100

Hi,

> I looked at your document and I see that section 5 is  a "Minimum set of 
> Signed Attributes." To try to prevent the problem I cited, it really 
> needs a definitive list of the objects and attributes that MAY be 
> signed, with a prohibition on signing any other objects/attributes.  
> This is the opposite of what your text says, as it allows the signer to 
> include whatever other attributes the signer wishes.
> 
> The name of an AS is NOT something that can be validated using the RPKI, 
> and this needs to made clear to folks using this mechanism. The same is 
> true for net name, org, country and status. The simplest thing to do 
> would be to exclude these as signed attributes. I am not very familiar 
> with the attributes you listed for the four object types, but I suspect 
> that a more of them will fall into this category.

The intention here is that the owner of the resources can make verifiable 
statements. They can claim, by constructing and signing RPSL objects, that 
certain facts are true regarding the use of the resource; in other words, 
this mechanism allows the holder of the resources to bind their resources 
and other info together. So it's really intentional that other attributes 
such as org name, AS name, import/export attributes, contact info, ... can 
be covered by the signature, even though these are not number resources.

If we state that the only attributes that can be signed are the ones that 
carry number resources, and which can also be found in the covering 
certificate (ie. your "maximum set" approach, if I understand correctly), 
then there is no practical gain for the signature. The only only meaning for 
such an object in my interpretation would be "The resource holder has 
spoken. They said they have an object." without any verifiable claims about 
the actual content of the object.

Based on this, I believe that the current "minimum set" specification is the 
right approach.

> constitutes validation based on an appropriate cert or ROA, i.e., what 
> checks MUST be performed by the RP to ensure that the signed 

Very good suggestion, I completely agree with it.

Regards,
Robert

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Dec 2008 10:55:02 -0500

At 9:52 AM +0100 12/3/08, Robert Kisteleki wrote:
>Hi,
>
>>Robert,
>>
>>Thanks for the clarification., but I still have some serious 
>>concerns that I think need to be addressed as we progress this as a 
>>WG item.
>>
>>I looked at your document and I see that section 5 is  a "Minimum 
>>set of Signed Attributes." To try to prevent the problem I cited, 
>>it really needs a definitive list of the objects and attributes 
>>that MAY be signed, with a prohibition on signing any other 
>>objects/attributes.  This is the opposite of what your text says, 
>>as it allows the signer to include whatever other attributes the 
>>signer wishes.
>>
>>RPKI, and this needs to made clear to folks using this mechanism. 
>>The same is true for net name, org, country and status. The 
>>simplest thing to do would be to exclude these as signed 
>>attributes. I am not very familiar with the attributes you listed 
>>for the four object types, but I suspect that a more of them will 
>>fall into this category.
>
>The intention here is that the owner of the resources can make 
>verifiable statements. They can claim, by constructing and signing 
>RPSL objects, that certain facts are true regarding the use of the 
>resource; in other words, this mechanism allows the holder of the 
>resources to bind their resources and other info together. So it's 
>really intentional that other attributes such as org name, AS name, 
>import/export attributes, contact info, ... can be covered by the 
>signature, even though these are not number resources.

The problem is that the RPKI cert(s) used to verify such signed 
assertions do not attest to the accuracy of the other attributes. 
This means that we are allowing (really encouraging) relying parties 
to accept as accurate the data verified using RPKI certs, and that is 
dangerous.  It creates potential liabilities for the CAs in the RPKI. 
For example, if an ISP asserts in a signed object that it's name is 
Foo Corp, when in reality its name is Bar Co., this could create a 
liability for the registry that issued the CA cert to Bar Co. We have 
tried to avoid this sort of liability by restricting the subject 
names in resource certs to be non-meaningful, and this proposal 
reintroduces this liability.

>If we state that the only attributes that can be signed are the ones 
>that carry number resources, and which can also be found in the 
>covering certificate (ie. your "maximum set" approach, if I 
>understand correctly), then there is no practical gain for the 
>signature. The only only meaning for such an object in my 
>interpretation would be "The resource holder has spoken. They said 
>they have an object." without any verifiable claims about the actual 
>content of the object.

I think you are underestimating what could be done, but maybe I don't 
know enough about RPSL. Let me give an example:

	 If an ISP signs an object that asserts that it announces 
routes for several prefixes, then this assertion could be verified 
using a combination of the ROAs that attest to the origin AS info for 
each prefix, plus the transitive verification of similar records 
signed by other ISPs. That would provide the sort of static 
connectivity verification that soBGP proposed. This is an example  of 
a set of assertions that could be verified using data to which the 
RPKI attests.

>
>Based on this, I believe that the current "minimum set" 
>specification is the right approach.

I have to disagree. I think the proposal suffers from many of the 
same security problems that arise if one uses (non-resource) certs 
for authentication of RPSL data today, i.e., what you enable is an 
authenticated entity to make arbitrary assertions about arbitrary 
data.

Steve