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

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Jul 2018 09:36:41 -0700

Warren Kumari 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:
----------------------------------------------------------------------

Thank you for writing this - it solves a useful purpose, and is clear and easy
to read.

I had 2 comments / questions - please also see Tim Chown'sOpsDir review for a
useful nit.

Section  2.  Object Naming Practice
The entire 'HYPHEN-MINUS' selection makes me slightly twitchy - the argument
that it was chosen because it is commonly already used as a separator feels
like it cuts both ways - the fact that 'Handles can themselves contain
HYPHEN-MINUS characters' already seems to argue that a different separator
should have been chosen to minimize the chance of collisions / people getting
this wrong.  I get that the document says "the service provider identifier is
found following the last HYPHEN-MINUS character in the tagged identifier", and
would feel more comfortable if some of the examples contained more than one
hyphen to make this clearer.

Section 7. Security Considerations
'The transport used to access the IANA registries can be more secure by using
TLS [RFC5246], which IANA supports.' I'm confused by this sentence in the
Security Considerations section - more secure than what, not using TLS? Why
isn't this something like "The transport used to access the IANA registries
SHOULD (or MUST) be over TLS"?

---

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

> -----Original Message-----
> From: Warren Kumari <[email-masked]>
> Sent: Monday, July 30, 2018 12:37 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Gould, James
> <[email-masked]>; [email-masked]; Gould, James
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: [EXTERNAL] Warren Kumari's No Objection on draft-ietf-regext-
> rdap-object-tag-04: (with COMMENT)
>
> Thank you for writing this - it solves a useful purpose, and is clear and
> easy to read.
>
> I had 2 comments / questions - please also see Tim Chown'sOpsDir review
> for a useful nit.
>
> The entire 'HYPHEN-MINUS' selection makes me slightly twitchy - the
> argument that it was chosen because it is commonly already used as a
> separator feels like it cuts both ways - the fact that 'Handles can
> themselves contain HYPHEN-MINUS characters' already seems to argue that a
> different separator should have been chosen to minimize the chance of
> collisions / people getting this wrong.  I get that the document says "the
> service provider identifier is found following the last HYPHEN-MINUS
> character in the tagged identifier", and would feel more comfortable if
> some of the examples contained more than one hyphen to make this clearer.

Thanks for the review, Warren. We actually had quite a debate in the WG about the separator character (witness the change log). I could change one of the examples in Section 2 if that would be helpful.

> 'The transport used to access the IANA registries can be more secure by
> using TLS [RFC5246], which IANA supports.' I'm confused by this sentence
> in the Security Considerations section - more secure than what, not using
> TLS? Why isn't this something like "The transport used to access the IANA
> registries SHOULD (or MUST) be over TLS"?

Benjamin also had a comment about this text. I proposed this change in my reply to him:

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.

Better? I hesitate to say "The transport used to access the IANA registries SHOULD (or MUST) be over TLS" because that's not something the RDAP client controls - it's controlled by IANA's web server (which, in fact, is currently redirecting http connections to https).

Scott

---

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

> Better? I hesitate to say "The transport used to access the IANA registries SHOULD (or MUST) be over TLS" because that's not something the RDAP client controls - it's controlled by IANA's web serve…

Well, to a large extent it *is* something the RDAP client controls.  If it
starts out with http and waits to be redirected to https, it retains all
the security vulnerabilities of unencrypted http, including the ability for
an attacker to inject traffic with a fake reply, redirect to an
attacker-controlled server, etc.  An RDAP client that insists on TLS (to
IANA) and performs certificate verification is assured of either getting
validated data from IANA or a connection failure.  Perhaps that's not
always the best desired behavior, but it seems like it would be desired
almost all of the time (hence, SHOULD).

-Benjamin

---

From: Warren Kumari <[email-masked]>
Date: Tue, 31 Jul 2018 11:29:59 -0400

> Thanks for the review, Warren. We actually had quite a debate in the WG about the separator character (witness the change log). I could change one of the examples in Section 2 if that would be help…

Okey dokey - my main concern is if the WG discussed it and selected
something; I'm not yet quite so arrogant that I'm sure I know better
than the WG :-)
I think that having an example with multiple hyphens would be helpful
to avoid issues.

> Better? I hesitate to say "The transport used to access the IANA registries SHOULD (or MUST) be over TLS" because that's not something the RDAP client controls - it's controlled by IANA's web serve…

I'd think that a SHOULD is fine - I cannot imagine the IANA disabling
HTTPS for registries like this, but won't dig in my heels over this...

W

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf