Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-rdap-object-tag-04: (with COMMENT)

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Tuesday, July 31, 2018 9:51 AM
> To: Hollenbeck, Scott <shollenbeck=[e-mail]>
> Cc: '[e-mail]' <[e-mail]>; '[e-mail]' <regext-
> [e-mail]>; '[e-mail]' <[e-mail]>; Gould, James
> <[e-mail]>; '[e-mail]'
> <[e-mail]>
> 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 <[e-mail]>
> > > Sent: Friday, July 27, 2018 1:52 PM
> > > To: The IESG <[e-mail]>
> > > Cc: [e-mail]; Gould, James
> > > <[e-mail]>; [e-mail]; Gould, James
> > > <[e-mail]>; [e-mail]
> > > 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.

> > > 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.

> > > 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.

> > > 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.

Scott