Re: [secdir] Secdir review of draft-ietf-sidr-rpsl-sig-10

[Brian Haberman <[e-mail]>]

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.

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.

> - 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.

> 
> 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.

> - "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.

> - 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.

> 
> 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.

Regards,
Brian