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

From: Magnus Nyström <[email-masked]>
Date: Sun, 8 May 2016 23:55:31 -0700

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

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

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?
- It would be very helpful with a full example, not just an outline as in
2.3.
- 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"?

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

-- Magnus

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 May 2016 09:33:29 -0400

Hi Magnus,
    Thanks for the review and comments. Responses are in-line...

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

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

> no need for protocol action / IANA action to register new algorithm for use

We don't think so. This approach follows the approach of RFC 4055.

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

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

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

> objects need such a certificate, but not necessarily all maintainers?

Agreed that "a maintainer" can be changed to "the creator".

> 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

I will try and generate one.

> stated that each attribute (and the signature is an attribute too), must be

This will be applicable when text removed in an earlier version is
restored that allows for multiple signatures.

> example (note: I am not too familiar with RFC 6487 so may be missing

Correct. This should be signature generation.

Thanks for the feedback.

Regards,
Brian

---

From: Magnus Nyström <[email-masked]>
Date: Fri, 13 May 2016 08:47:52 -0700

Thanks Brian,

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

> Yes, that may be helpful.

> that

Much better, thanks.

> signature. The attributes listed in "a" need to be in the object.

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

> restored that allows for multiple signatures.

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

> Thanks

-- 
-- Magnus