[secdir] SecDir review of draft-ietf-sidr-publication-09

[Paul Wouters <[e-mail]>]

SecDir review of draft-ietf-sidr-publication-09

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 is Almost Ready.

Title and intro say:

"A Publication Protocol for the Resource Public Key Infrastructure (RPKI)"

"This document defines a protocol for publishing Resource Public Key
Infrastructure (RPKI) objects. "

It seems the protocol is not just about publication, but also about
withdrawing publications. I would call that "Maintaining" rather than
"Publishing" and also brings up the question of who can make changes and
how those are secured and/or validated. However, the document's Security
Considerations places all of the client authentication and authorization
as "out of scope" and deems this is protected securely.

I do think that this document should explain when a publication or
withdrawal request is received using this protocol, what should be
checked before allowing the transaction. This could be something as
simple as a reference to another document, or some text in this document.

Is there another document that describes consuming this information?
If not, shouldn't this document contain some information on how to safely
consume this data?

It feels to me this document is only describing transport of RPKI
objects between a client and a publication server, but does not describe
how to consume this data on the server side or how to consume the
published/withdrawn data as a client. Perhaps a title adjustment is in
order to clarify that?

The Security Considerations doenot talk about the security impact of
"Publication". The document really describes the transport of the data
and not the publication of the data. So again, this might be correct if we
had a more appropriate title for this document.  Now I am left wondering
if this "publication" is compromised, populated with bogus data, or made
unavailable in general, what happens. If this is documented in another
document, a reference should be added.

It seems a natural fit to perform some kind of transparency (audit)
logs for RPKI announcements. Why not use Certificate Transparency and
leverage existing standards and software? Which would include monitoring,
auditing and gossiping of this data in a distributed way. Are we talking
about too much (changing) data for the CT model to handle?

The term PDU is not expanded on first use, and not described anywhere,
not even in the "required reading" of RFC-6480. I still do not know what
it actually stands for.

Section 2.2 has a reference [SHS] for SHA-256 to a non-RFC document.
Why not refer to RFC-4634 instead?

What would be the criteria for a client to be allowed to publish or
withdraw an object? Apparently the data is signed (with [CMS]) but I
find no discussion of client/server or data authenticaiton/authorization
other then "out of scope". How is it prevented that one client can update
another clients object?

I'm little nervous about hardcoding SHA-256 but it seems to be mostly used
as an uniqueid lookup identifier and other access controls are supposed to
be in place to prevent abuse. Hopefully there will be some client-server
authentication that would further protect a rogue client from modifying a
(hash collision based) object identified by a SHA-256 hash so a client
can only delete its own (or its group?) objects. Should some of this be
discussed in the Security Considerations? I also assume creating a hash
collision would require stuffing weird data inside, which would hopefully
get detected. But no where does it mention that as part of accepting a
publication, someone is checking the content of the RPKI object.

    "Note the authors have taken liberties with the Base64, hash, and
    URI text in these examples in the interest of making the examples
    fit nicely into RFC text format."

While I understand that, I think it is still not a good idea to write:

 	hash="01a97a70ac477f06"

in the example as an example of a SHA-256 hash. I would prefer:

 	hash=<SHA256-Hash>

or

 	hash="<hex(SHA256-Hash)>"

or even:

 	hash="01a97a70[...]ac477f06"

In this case it actually shows some confusion too. The SHA256 hash is
probably not in its binary format, but in hex format, which should be
stated more clearly in the document.

Similarly, it seems the blobs submitted are base64 blobs, even though it
does not actually state that anywhere in this document. It could be that
all RPKI objects are base64, in which case this comment can be ignored.

I also find the following usage confusing:

 	error_code="no_object_matching_hash"

When we talk about error code, we normally really mean a number like
404, not a string. If we name such strings, we tend to use upper case,
like NO_OBJECT_MATCHING_HASH, but that might be my C experience.

I would personally also avoid single quotes in the text message and write
"Can not" and "Do not" instead of "Can't" and "don't" to avoid confusion
about when to mask single quotes in xml syntax.

What is the data in the "tag" supposed to be. Since the hash is used
to identify the objects, it seems like some human readable aid? Is it a
"query id" kind of identifier? Can these be the same for multiple objects?
If no one owns these and how are clients preventing from using another
client's tag ? Or can clients use unixtime as a tag and get into a
race condition? I feel that I should probably understand tag better,
but again this document nor RFC-6480 describes what a tag is.


Reading secion 4, it seems "tag" is really "client ID". But it is not
clear to me how one client is prevented from using another client's tag?
Or if it is authenticated, how tags are registered with clients?

Section 4 mentions "<client/> setup messages" without explaining what
this is, and it is not obvious to me.

The Security Consideration puts client authentication as out of scope
of this document. I think that is fine, assuming my above questions are
answered (possibly filling in my lack of knowledge of RPKI, or possibly
by adding clarifying text to the document.

Paul