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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Jul 2018 10:51:36 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-rdap-object-tag-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/

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

Also, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/, please
consider using IPv6 addresses in the examples.

Section 5.1

Are all provided URLs supposed to be functionally different?  If not, how
do we tell which ones do what?

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?

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 30 Jul 2018 14:29:02 +0000

(My email client sometimes does unexpected things with message encryption. Sending again with plaintext assured...)

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Friday, July 27, 2018 1:52 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Gould, James
> <[email-masked]>; [email-masked]; Gould, James
> <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Benjamin Kaduk's No Objection on draft-ietf-regext-
> rdap-object-tag-04: (with COMMENT)
>

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.

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

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

> data from an authoritative source?

Sure, OK.

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

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 31 Jul 2018 11:24:39 +0000

> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/

Sorry, I missed this in the response I sent yesterday.

No, there wasn't any significant discussion about this. The concept was introduced to the WG as documenting an existing practice (both ARIN (ex: ABUSE5603-ARIN) and Verisign (ex: 484689367_DOMAIN_COM-VRSN) tag entity identifiers this way, for example), and the WG appears to have accepted that proposal based on the lack of disagreement.

Scott

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Jul 2018 08:51:14 -0500

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

> 7483. I'd prefer to keep it as-is to maintain consistency with that cited 

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

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

> 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