Thanks Brian,

On Wed, May 11, 2016 at 6:33 AM, Brian Haberman <brian@innovationslab.net>
wrote:

> Hi Magnus,
>     Thanks for the review and comments. Responses are in-line...
>
> On 5/9/16 2:55 AM, Magnus Nyström wrote:
> > I have reviewed this document as part of the security directorate's
> ongoing
> > effort to review all IETF documents being processed by the IESG. These
> > comments were written primarily for the benefit of the
> > security area directors. Document editors and WG chairs should treat
> these
> > comments just like any other last call comments.
> >
> > This document describes a mechanism for digitally signing Routing Policy
> > Specification Language (RPSL) objects. The digital signatures are
> intended
> > to ensure authenticity and integrity protection of such objects when they
> > are transferred to and from resource databases.
> >
> > - The signature scheme is a little unusual in that the signature
> attribute
> > lists the names of the attributes that are part of the signature rather
> > than just including those attributes (and their values) as part of the
> > signature attribute itself; I assume this is due to a need to preserve
> > established RPSL object syntax but it doesn't seem required for this
> > application which essentially is a transport format. The cost here is, of
> > course, the need to duplicate the names of the signed attributes in the
> > signed RPSL object (once for the regular attribute value and once for the
> > value in the signature attribute).
>
> As noted in Section 2, this approach is similar to the one taken by
> DKIM. It is designed to allow backwards compatibility with systems that
> have not been upgraded to recognize the new signature attribute.
>
> > - There is an expectation that relying parties fetch the signer's
> > certificate based on a URL in the signature attribute. This may be a
> > dangerous practice, since the URL needs to be contacted before the
> > signature can be validated. A malicious party may insert a URL that will
> > lead to an attack. I suggest this be noted in the Security Considerations
> > section with some suggested best practice, e.g., only https and careful
> > parsing of the retrieved resource.
>
> It is unclear to the authors what "careful parsing" means here and
> HTTPS-only in the context of RPKI-hosted certificates creates other
> complications that may exceed the benefits.
>

Well, it seems to me that the ability to get agents to contact an
unverified URL is a potential risk and I would recommend some discussion
around this in the Sec Cons section..

>
> I would suggest that we add a pointer to Section 7 of RFC 6487 to the
> Security Considerations section of this draft. That portion of 6487
> describes the certificate validation methodology for these certificates.
>
> > - The Signature Method field - how are new algorithms identified? Is
> there
> > no need for protocol action / IANA action to register new algorithm for
> use
> > with this memo?
>
> We don't think so. This approach follows the approach of RFC 4055.
>
> > -- As for the canonicalization, this is an inherently complicated field.
> It
> > does not, for example, seem as if the memo describes how to canonicalize
> > multi-valued attributes. The ordering of such values may well be
> > implementation-dependent post object parsing and thus, the
> canonicalization
> > should cover how to order sets or sequences of values.
>
> In my experience, RPSL servers do not modify the order of sets or
> sequences when importing/exporting objects. The necessary
> canonicalization text for such objects is mentioned in point #5 of
> section 3.1.
>
> If you think it would help, we could add something along the lines of
> "The ordering of multi-valued attributes in c14n must preserve the
> original ordering in the object" to point #5 in 3.1.
>
> I would suggest this, since in general canonicalization should allow to
first parse a received message and then later do verification with a
successful result without relying on implicit expectations on behavior.

> - The last paragraph of the Security Considerations brings up an important
> > point but provides no guidance to an implementer how to handle this case
> /
> > detect the situation. Preferably some advice should be given here.
>
> An entity is free to sign whatever attributes it wants. So, it is up to
> the consumer to decide what attributes he/she cares about. Given that we
> can add a sentence to the Security Considerations section saying that
> consumers of signed RPSL objects may validate signed resource attributes
> if methods exist to do so.
>
> Yes, that may be helpful.


> >
> > Editorial / questions:
> >
> > Section 1:
> > - "This means when downloading a Routing Policy Specification Language
> > (RPSL) object stored in this database, one can reasonably safely claim
> that
> > the object is authentic, but for an imported object one cannot." Two
> > points: First part of sentence likely misses a "that." Secondly, what's
> > referred to with "this" database?
>
> Would the following be more clear?
>
> OLD:
>
> This means when downloading a Routing Policy Specification Language
> (RPSL) object stored in this database, one can reasonably safely claim
> that the object is authentic, but for an imported object one cannot.
>
> NEW:
>
> This means that when a Routing Policy Specification Language (RPSL)
> object is downloaded from a database, the consumer can reasonably claim
> that the object is authentic if it was locally created, but cannot make
> the same claim for an object imported from a different database.
>

Much better, thanks.

>
> > - "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." Why does a maintainer of objects need to
> possess
> > a resource certificate? I think the party generating signed database
> > objects need such a certificate, but not necessarily all maintainers?
>
> Agreed that "a maintainer" can be changed to "the creator".
>
> >
> > Section 2:
> > - "When verifying the signature of an object, the verifier has to check
> > whether the signature itself is valid, and whether all the specified
> > attributes are referenced in the signature." What "specified" attributes?
>
> The list of signed attributes is identified by the "a" field in the
> signature. The attributes listed in "a" need to be in the object.
>

I would suggest "all the attributes specified in the "a' field".

>
> > - It would be very helpful with a full example, not just an outline as in
> > 2.3.
>
> I will try and generate one.
>
> > - Section 2.4 talks about multiple signatures. I believe this is the only
> > place where this is done, and it is also confusing given that earlier
> text
> > stated that each attribute (and the signature is an attribute too), must
> be
> > present "at most once"?
>
> This will be applicable when text removed in an earlier version is
> restored that allows for multiple signatures.
>

Is that intended to be restored before publication? If not, suggest
removing.

>
> >
> > Section 5:
> > - The certificate shouldn't be used for more than one verification - was
> > the intent to say that the private key associated with the public key
> > present in the certificate shouldn't be used to sign more than one RPSL
> > object? It seems difficult to state that a certificate can be used for
> > verification only once - multiple relying parties may verify it, for
> > example (note: I am not too familiar with RFC 6487 so may be missing
> > something here).
>
> Correct. This should be signature generation.
>
> Thanks for the feedback.
>
> Thanks


> Regards,
> Brian
>
>
>


-- 
-- Magnus