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

[Terry Manderson <[e-mail]>]

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" <[e-mail]> 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/
> 
> 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
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr