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

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Jan 2017 17:17:08 -0500 (EST)

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

---

From: Rob Austein <[email-masked]>
Date: Mon, 09 Jan 2017 19:55:12 -0500

Hi, Paul.  Thanks for the review!  Sorry about taking so long to get
back to you on it, but there was a bit more to yours than just "fix
these few nits".

I'm not going to attempt to answer point by point, because that would
drive us both nuts.  Instead, I'm going to answer a few specific
points, then let you see if the text changes I made are satisfactory.

Overall, this required a bit more new text than I would have preferred
at the end of Last Call, but I think you identified some missing
background information that needed adding, and none of the new text is
intended to change the protocol itself in any way, so I'm hoping this
will be acceptable to all parties.

To specific points, in no particular order:

* Authentication was covered in the doc, but I added a bit more text
  to make it a bit more obvious.  Authorization is a private matter
  between client and server operators (just as it would be when
  signing up for any application protocol, eg, an IMAP account), but I
  added a bit of text to make that more obvious too.

* See the new ASCII art in the introduction for how this protocol fits
  into the overall picture, and, in particular, why this protocol is
  indeed mostly concerned just with shipping RPKI objects between
  certificate engines and publication servers rather than what the
  RPKI relying parties do with those objects.

  Many thanks to Randy Bush for providing the ASCII art.

* We've been calling this the "RPKI publication protocol" for about
  ten years now, so, with respect, we would prefer not to change that.
  One could quibble about whether the ability to withdraw published
  objects is implied by the ability to publish both new and updated
  objects, but, really, it's a name, and it is what it is.

* Certificate Transparency is an interesting idea, and if somebody had
  raised it a year ago I might have been interested in exploring it,
  but we're dealing with a protocol that should have shipped years
  ago, which is now part of a bundle of other RPKI-related protocols,
  and which is trying to keep its use of CMS compatible with RFC 6492,
  so I'd really rather not go back to the drawing board on this one
  right now.  My preference would be to leave this as a topic for
  future work, to be handled in an updated specification if and when
  somebody gets a chance to look into it properly.

* "PDU" stands for "Protocol Data Unit". it's an old ITU term which
  entered the IETF lexicon via SNMP, IIRC.  Anyway, it's an
  RFC-Editor-blessed abbreviation, see:

  https://www.rfc-editor.org/materials/abbrev.expansion.txt

* We use [SHS] as the reference for SHA-256 because that's what
  somebody advised us to do, years ago.  I'm fine with changing that
  to RFC-4634 if that's what the IESG wants us to do this year.

* I did not take your recommendation on changing the examples.
  There's a very specific reason why we wrote the examples the way we
  did: because they're syntactically correct XML, we can run them
  through the RelaxNG schema checker to make sure we didn't mess up
  the syntax.  Your preferred form ("hash=<SHA256-Hash>" or whatever)
  would not pass that syntax check, so we'd be back to (error-prone)
  manual checking of the example syntax.  Been there, broke that.

  In an attempt to meet you part way on this, I added XML comments to
  some of the examples, which I hope will suffice to address this.

* The text already said that the various DER blobs are encoded in
  Base64, as does the schema.  Syntax of hash attributes is nailed
  down pretty tightly as hexadecimal in the schema but was not
  explicit in the text (oops): fixed, thanks!

* "<client/>" was an editorial oversight, it was old text that should
  have been removed at the same time as the mechanism to which it was
  referring was taken out (at the WG's request).  Thanks for catching
  that.

* "tags" in this protocol are transaction IDs, modeled roughly on the
  tags in IMAP4.   I added some text making this more explicit.

I have not yet submitted the updated I-D (-10).  Will do so tomorrow
unless I hear loud screaming, as our AD wants an updated I-D this
week.  For the moment, you can see the updated version and a diffs at:

https://subvert-ietf.hactrn.net/sidr-publication/draft-ietf-sidr-publication-10.txt
https://subvert-ietf.hactrn.net/sidr-publication/draft-ietf-sidr-publication-10-from-09.diff.html

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Jan 2017 23:49:42 -0500 (EST)

> will be acceptable to all parties.

The text and your email clarified a lot. Thanks!

> https://subvert-ietf.hactrn.net/sidr-publication/draft-ietf-sidr-publication-10-from-09.diff.html

I've read the changes. Those along with the clarifications in your email
resolve all my issues. So from a SecDir review point of view, this
document is now Ready.

Thank you,

Paul

---

From: Rob Austein <[email-masked]>
Date: Tue, 10 Jan 2017 08:33:36 -0500

At Mon, 9 Jan 2017 23:49:42 -0500 (EST), Paul Wouters wrote:
...
> resolve all my issues. So from a SecDir review point of view, this

Cool.  Thanks!