Skip to main content

Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
draft-ietf-sidr-rfc6490-bis-05

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