On Mon, Jul 30, 2018 at 02:29:02PM +0000, Hollenbeck, Scott wrote: > (My email client sometimes does unexpected things with message encryption. > Sending again with plaintext assured...) > > > -----Original Message----- > > From: Benjamin Kaduk <ka...@mit.edu> > > Sent: Friday, July 27, 2018 1:52 PM > > To: The IESG <i...@ietf.org> > > Cc: draft-ietf-regext-rdap-object-...@ietf.org; Gould, James > > <jgo...@verisign.com>; regext-cha...@ietf.org; Gould, James > > <jgo...@verisign.com>; regext@ietf.org > > Subject: [EXTERNAL] Benjamin Kaduk's No Objection on draft-ietf-regext- > > rdap-object-tag-04: (with COMMENT) > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I was a little surprised to see that this document targets BCP status, not > > Proposed Standard. Was there much discussion of this question in the WG? > > > > Section 2 > > > > Service provider tags are concatenated to the end of RDAP query > > object identifiers to unambiguously identify the authoritative server > > > > It seems like it is the combination of concatenation of the service > > provider tag, and the use of the rdap_objectTag_level_0 rdapConformance > > attribute that provides the unambiguous property; I would like to see this > > caveat made more clear here. > > Thanks for the review, Benjamin. The rdapConformance attribute doesn't do > anything to identify the authoritative server. It's a clue to the client that > the server has implemented this particular practice.
Right, it's an indication that the server has implemented this practice. Absent such an explicit indication, the -XXXX tag could either be a service provider tag, or just a regular part of the query handle. Thus, just the convention of an -XXXX tag by itself is *not* unambiguous. So, I'm asking for some text to be added that qualifies the statement as only applying "when the client knows that this convention is in use" (or similar). > > Also, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/, please > > consider using IPv6 addresses in the examples. > > The example copied into this document comes directly from Section 5.3 of RFC > 7483. I'd prefer to keep it as-is to maintain consistency with that cited > reference. I note that the IAB statement is not exactly binding, but also that at some point blindly propagating the same example into the future becomes stuck in a history that does not reflect the present. (I also note that my ART colleagues are generally more active on this front than I am.) > > Section 5.1 > > > > Are all provided URLs supposed to be functionally different? If not, how > > do we tell which ones do what? > > Practice thus far in the RDAP bootstrap registries has been to register http > and https URLs. The scheme of the URL identifies the functional difference. Perhaps indicate that they are expected to supply the same data, but may differ in scheme or other components? > > Section 7 > > > > Perhaps note that it is using IANA as a well-known central trusted > > authority in order to provide the property of allowing users to get RDAP > > data from an authoritative source? > > Sure, OK. > > > [...] The method has the same security > > properties as the RDAP protocols themselves. The transport used to > > access the IANA registries can be more secure by using TLS [RFC5246], > > which IANA supports. > > > > Well, I don't know that "the same as" is quite right, especially given the > > following sentence. The composed chain of "talk to iana, talk to referred > > RDAP server" depends both on the security of the connection to the RDAP > > server and that of the connection to IANA; it seems prudent to note that > > if TLS is used for the RDAP connection, TLS should also be used when > > talking to IANA, or even that TLS should always be used when talking to > > IANA. > > OK, how about this text? > > OLD: > This practice helps to ensure that end users will get RDAP data from an > authoritative source using a bootstrap method to find authoritative RDAP > servers, reducing the risk of sending queries to non-authoritative sources. > The method has the same security properties as the RDAP protocols themselves. > The transport used to access the IANA registries can be more secure by using > TLS [RFC5246], which IANA supports. > > NEW: > This practice uses IANA as a well-known, central trusted authority to provide > the property of allowing users to get RDAP data from an authoritative source, > reducing the risk of sending queries to non-authoritative sources and > divulging query information to unintended parties. Additional privacy > protection can be gained by using TLS [RFC5246] to provide data > confidentiality when retrieving registry information from IANA. I like the overall direction this is going, but have some quibbles. For one, TLS is not just about confidentiality protection and privacy concerns -- it also provides integrity protection and authentication of the data source. For consulting a central registry like this, the integrity protection and data authenticity seem to be potentially more important than confidentiality, at least from where I'm sitting. I also think it's fine to retain some text about "the same security properties as the RDAP protocols themselves", when appropriately set into context. Perhaps: NEWNG: This practice uses IANA as a well-known, central trusted authority to allow users to get RDAP data from an authoritative source, reducing the risk of sending queries to non-authoritative sources and divulging query information to unintended parties. Using TLS [RFC 5246] to protect the connection to IANA allows the server to authenticate itself as being operated by IANA and provides integrity protection for the resulting referral information, as well as providing privacy protection via data confidentiality. The subsequent RDAP connection is performed as usual, and retains the same security properties of the RDAP protocols themselves. -Benjamin _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
