On Wed, Aug 01, 2018 at 12:51:37PM +0000, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Benjamin Kaduk <ka...@mit.edu> > > Sent: Tuesday, July 31, 2018 9:51 AM > > To: Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org> > > Cc: 'i...@ietf.org' <i...@ietf.org>; 'regext-cha...@ietf.org' <regext- > > cha...@ietf.org>; 'regext@ietf.org' <regext@ietf.org>; Gould, James > > <jgo...@verisign.com>; 'draft-ietf-regext-rdap-object-...@ietf.org' > > <draft-ietf-regext-rdap-object-...@ietf.org> > > Subject: [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf- > > regext-rdap-object-tag-04: (with COMMENT) > > > > 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). > > OK, so how about changing this line in Section 2? > > OLD > Service provider tags are concatenated to the end of RDAP query object > identifiers to unambiguously identify the authoritative server for processing > an RDAP query. > > NEW > In combination with the rdapConformance attribute described in Section 4, > service provider tags are concatenated to the end of RDAP query object > identifiers to unambiguously identify the authoritative server for processing > an RDAP query.
That helps; thanks! > > > > 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.) > > I very much prefer to keep the example consistent with 7483 since it is > included ONLY to show how addition of an object tag would change the example. > I could strike other values from the example (including the IP addresses) if > that would help. I won't press you to make any changes, here, for now. > > > > 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? > > OK, how about this change? > > OLD > One or more URLs that provide the RDAP service regarding this registration. > > NEW > One or more URLs that provide the RDAP service regarding this registration. > The URLS are expected to supply the same data, but they can differ in scheme > or other components as required by the service operator. Sounds good. > > > > 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. > > OK, I'll make this change assuming that it addresses Warren's feedback as > well. Thanks! -Benjamin _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
