Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpsl-sig-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 19 May 2016 05:33:48 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-rpsl-sig-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks all for chatting about my discuss, I think the
outcome is good.

--- OLD COMMENTS below, I didn't check 'em, feel
free to chat more or not, as you think best.

- If you keep the potential for http(s) URIs then I think
more text is needed in the security considerations but
it looks like you're taking that out for now so I guess
that's ok. 

- 2.1, I don't see why it's useful to allow variation in the
fields of the signature attribute e.g. why "MAY" the version
not be 1st?

- 2.1, "t=" and "x=" any limits on precision here?
(Non-)support for fractional seconds can be a source for
non-interop if not. The "All times MUST be converted to" is
also actually a little ambiguous as you don't say to do that
before signing;-)

- 2.1, "a=" did you want a lowercase "must" there?

- Are steps 2 and 3 in 3.1 order-sensitive? I think you
might sometimes need to do 2 after 3, or re-do 2 maybe or
else leading whitspace could be an issue. Maybe say that
sometimes you need to do step 2 >1 time?  

- 3.1, oops, an ambiguity - in "The following steps MUST be
applied in order..." does "in order" mean "in the order
below" or "so as to"? I assume the latter.

- 3.1: In general I think you'd be better if you pointed at
specific bits of text in all the RFCs mentioned in 3.1 -
it's maybe easy to get wrong otherwise, esp. if we don't yet
have >1 implementation. 

- 3.1, step 6: names are all ASCII right? just checking

- 3.2, step 1 - given 3.3 step 2, you're missing a step to
"publish the cert" at the c= location as well.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 May 2016 08:53:20 -0400

Stephen, et al.,

A couple of observations about the topic of certs used to verify RPSL sigs:

     - the title of the I-D says that it relies upon the RPKI, and, as 
currently
written, it mandates use of RPKI certs. So, using certs from a different PKI
would require a re-write. Also, the security of the system would be reduced
if other certs were employed, wrt verification of assertions about address
space and ASN holdings. So, I don't think it's appropriate to suggest 
alternative
PKIs. I also note that the text on page 3 that says "equivalent 
functionality can
be achieved" using an alternative PKI is questionable. Merely having 
3379 extensions
in a cert does not mean that all of the other security-relevant elements 
of the RPKI
accrue. (Also, there is a typo: certificate authority" -> "certification 
authority")

     - if one is using RPKI EE certs, as currently mandated, then the 
single use
requirement (which is imposed on CAs, but RPs are not required to 
verify) applies.
Deliberate re-use of a cert would mean that the CA violated the cert 
policy, and
thus the cert ought not contain the RPKI policy ID, etc. Also, the 
Security Considerations
section of the I-D refers to 6487, which is appropriate only if we're 
discussing RPKI certs.

     - The phrase "money-in-the-middle" is cute, but Randy's terminology 
is not widely
adopted. I suggest using the more conventional terminology that a wider 
range of
readers will recognize.

Steve