Subject: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 24 May 2012 23:06:17 +0000

The authors have stated that they believe that draft-ietf-sidr-rpsl-sig-05 "Securing RPSL Objects with RPKI Signatures" is ready for a working group last call.

The draft can be accessed at http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/

This announces the beginning of the wglc.  The last call will end on Friday, 08 Jun 2012.

Please judge whether you believe that this work is ready for publication and send any comments to the list.

--Sandy, speaking as wg co-chair

---

From: Randy Bush <[email-masked]>
Date: Fri, 25 May 2012 10:29:13 +0900

a quick read only.  and sorry to wait for wglc, but that's life.  at
least i did not wait for ietf lc :)

--

what is "RPSL"?  it is not defined, nor is there a cite.

--

2.1.  General Attributes, Meta Information

in general, the format/syntax of the attribute part of many fields might
be specified more precisely.  have mercy on the people who are gonna
write code to parse this stuff.  e.g. time "is expressed as the decimal
representation of an unsigned integer," but what is a decimal
representation?  ascii? (note that 3.1.4 does this) i'd even settle for
examples.  the "list of attribute names" needs to cite the enumeration
of allowed names, kinda hard if RPSL has no cite.  blah blah blah.

--

2.1.  General Attributes, Meta Information
   2.  Reference to the certificate corresponding to the private key
       used to sign this object (field "c").  This is a URL of type
       "rsync" or "http(s)" that points to a specific resource
       certificate in an RPKI repository.

needs a cite

--

2.1.  General Attributes, Meta Information
   3.  Signature method (field "m"): what hash and signature algorithms
       were used to create the signature.  The allowed algorithms which
       can be used for the signature are specified in [RFC6485].

sec folk, is this sufficiently specified that i can get a sure parse?
i am three levels deep in rfcs and am still not sure.

--

2.1.  General Attributes, Meta Information
   5.  The signed attributes (field "a").  This is a list of attribute
       names, separated by an ASCII "+" character (if more than one
       attribute is enumerated).  The list must include any attribute at
       most once.

as rfc 2622 has many attributes which are "multi-valued," which of the
set is being signed?

--

Optional fields of the "signature" attribute:

is it a field or an attribute?  both are used.  decide.

--

One applications for such a mechanism include the case of a route[6]
object, where both the prefix owner's and the AS owner's signature is
expected (if they are different parties).

first, this is an example of why a mild grammar pass is needed.

second, the trust model of the rpki ROA is that the AS owner does not
attest.  i do not remember the trust model in RPSL and am too lazy to
try to figure it out as it cites 2725 which says

   3. Routes should only be announced with the consent of the holder of
      the origin AS number of the announcement and with the consent of
      the holder of the address space.

but i just do not have the energy to find how this is stated, validated,
... in this way too looong doc.  but the difference in trust models
could be at least noted.

and i have this nagging worry that there is trouble waiting in that list
of urls of certs.  the references and referents are not necessarily
stable and the resulting instability of a collection of them could be
interesting.

--

2.2.  Signed Attributes
   One can look at an RPSL object as an (ordered) set of attributes

uh, i guess one could.  but my memory is that the are not strictly
ordered.  you may want to say if and why ordering is actually important
to this draft.

--

2.2.  Signed Attributes

trust model issue.  what attributes may [not] be signed by, for example,
a prefix cert?  may prefix certs [not] sign different fields/attributes
than AS certs?

--

   The type of the object determines the minimum set of attributes that
   MUST be signed.  The signer MAY choose to sign additional attributes,
   in order to provide integrity protection for those attributes too.

forward ref to sec 4 would be helpful here.

is integrity the only assertion being made if for signed attributes
beyond the minimum set?

with multiple signers, is, for example, the AS holder signing an route:
object really attesting to the holes: and org:?

--

why not mandate the canonic syntax of 3.1.4 in the objects themselves?

--

3.2.  Signature Creation
   3.  Arrange the selected attributes according to the selection
       sequence specified in the "a" field as above, omiting all
       attributes that will not be signed.

attributes which may be repeated are gonna be fun.

--

back to tex

randy

---

From: Terry Manderson <[email-masked]>
Date: Thu, 24 May 2012 18:35:08 -0700

These are my comments on the draft draft-ietf-sidr-rpsl-sig-05

In the Introduction (Para 3) it says:

" A maintainer of such signed database objects MUST possess a relevant
resource certificate which shows him/her as the legitimate holder of an
Internet number resource"

I'm afraid I'm confused on how you make the jump to saying a maintainer of
RPSL objects has a resource certificate which lists the resources 'shows
him/her as the legitimate holder.' There is no identity information in the
resource certificate.

Further (and in the Abstract) says " are done by the legitimate holder(s) of
the internet resources". I think this is misaligned. Many legitimate
resource holders (that aren't in the ISP game) outsource their routing
'stuff' and would probably palm off the creation of resource certs to
someone else who might then hold the private key - so I would argue that the
more correct approach here, is to say that:

"modifications of such database objects are authorized by the holder(s) of
the private key for the resource certificate that encompasses the the
Internet resources mentioned in those objects."

The second last sentence clarifies somewhat, but my point is that I don't
see that the maintainer::Resource Holder::Private Key Holder is a simple
straight line. (and I note that the mntner object has no additional
handling, so in a way the mntner and the private key and resource cert in
the 'signature:' attribute can be quite unrelated except for some IRR
process to assert some relationship, somehow. Is/was there any discussion on
why the mntner asserts no awareness of a signature or relevant published
rescerts that may come into play over the objects it is responsible for?)

Section 2.1, The new attribute signature looks to update RPSL (RFC2622)
shouldn't a 'updates' in the RFC header?

section 2.2, nit.  "Allowing the maintainer an object to select the
   attributes that are covered by the digital signature achieves the
   goals established in Section 1."

missing "of", should be:

   "Allowing the maintainer of an object to select the
   attributes that are covered by the digital signature achieves the
   goals established in Section 1."

In Signature Creation (3.2) I would like to see a pointer to section 4. You
have gone to the effort to provide a sensible list of the attributes in RPSL
objects to sign over (which I like!), might as well highlight this to the
reader in section 3 and also in the intro and abstract. For me this is an
important piece.

I think the security considerations section needs work. Your rightly point
out that confidentiality (as a public object) is not a concern. I would like
the "integrity of the RPSL object" reworded so that you are actually talking
about the attributes (section 4) of the RPSL object which are signed over.

There are no words about availability. I think it needs to be highlighted
that signing the objects still does not guarantee any level availability or
end to end integrity. It's whois. :-) Any object can be modified in transit
(MiTM) to drop the signature attribute and modify the RPSL contents should
an attacker wish to.

Can you provide a set of actual examples in an appendix? I am most
interested in seeing an example with the optional references to other
parties certificates field 'o'. and additional signatures. (section 2.1,
second number '2' bullet)

For the most part I have no strong objections to this document moving
forward.

Cheers
Terry

On 25/05/12 9:06 AM, "Murphy, Sandra" <[email-masked]> wrote:

> The authors have stated that they believe that draft-ietf-sidr-rpsl-sig-05
> "Securing RPSL Objects with RPKI Signatures" is ready for a working group last
> call.
> 
> The draft can be accessed at
> http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-05 and
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr