Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
RFC 7730
Yes
(Alvaro Retana)
No Objection
(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Terry Manderson)
Note: This ballot was opened for revision 04 and is now closed.
Alvaro Retana Former IESG member
Yes
Yes
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-08-04 for -04)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2015-08-04 for -04)
Unknown
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 Former IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-08-03 for -04)
Unknown
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 Former IESG member
No Objection
No Objection
(2015-08-05 for -04)
Unknown
- (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
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)
Unknown