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= or 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 " 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