Resource Public Key Infrastructure (RPKI) Trust Anchor Locator

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-08-04 for -04)
No email
send info
I agree with Alissa's comments.

I also have to wonder if adding more URLs could increase the attack surface for trying to insert a bogus trust anchor--but I will leave that to the security experts.

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2015-08-04 for -04)
No email
send info
I think it would be helpful to explain in Section 1 what the purpose is for having multiple URIs in a TAL. It is implied in Section 2.2 but would help to make it explicit.

Regarding this text in 2.2:

"In order to operational increase resilience, it is RECOMMENDED that the
   domain name parts of each of these URIs resolve to distinct IP
   addresses that are used by a diverse set of repository publication
   points, and these IP addresses be included in distinct Route
   Origination Authorizations (ROAs) objects signed by different CAs.”

I think it would be good to point out why one might construct a TAL with URIs that do resolve to the same address in the exceptional case. Alvaro pointed out one case to me offline (diversity of DNS resolution despite the address sharing), but it might help to make the exception case explicit.

(Spencer Dawkins) No Objection

Comment (2015-08-03 for -04)
No email
send info
Just as a nit - there are at least a couple of places in this draft, that are unchanged from RFC 6490, that say "this document" or "this approach", which made more sense to me looking at RFC 6490 than at a document that will obsolete RFC 6490 (I didn't know where "this" was pointing).

If anyone else finds that confusing, the authors might want to look at that.

(Stephen Farrell) No Objection

Comment (2015-08-05 for -04)
No email
send info

- (In response to Ben's comment:) Assuming this change
only represents a change to the  means to get more
anchor information, after you have the public key, and
that any additional into is protected with the key I
don't think there's any real security change here - this
is basically like having an anycast address for the host
in the current URI (from the security POV). If that's
wrong please do correct me.

- tbh, I don't find the new text describing the syntax
to be very clear. It says: "...where the URI section is
comprised of one of more of the ordered sequence of:    
   1.1)  an rsync URI [RFC5781],    
   1.2)  a <CRLF> or <LF> line break."

Exactly what is supposed to separate the URIs? 

- the example should show >1 URL really

(Brian Haberman) No Objection

Barry Leiba No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection