Subject: [regext] draft-ietf-regext-rfc7484bis: Requiring secure transport for accessing bootstrap registries

From: Marc Blanchet <[email-masked]>
Date: Tue, 25 Jan 2022 18:58:51 -0500

Hello,
 As part of the reviews of draft-ietf-regext-rfc7484bis-04 for Internet Standard, Benjamin Kaduk has commented as follows:

<BK>
Section 3

  The RDAP Bootstrap Service Registries, as specified in Section 13
  below, have been made available as JSON [RFC8259] objects, which can
  be retrieved via HTTP from locations specified by IANA.  The JSON

While in a certain technical sense, using HTTPS still qualifies as
"retrieved via HTTP", I'd suggest changing this to "HTTPS" to provide
more straightforward guidance to use the access mechanism that provides
integrity protection and source authenticity.

…

Section 11

                                                                  The
  transport used to access the registries can be more secure by using
  TLS [RFC8446], which IANA supports.

In a similar vein to Roman's comment, I note the following text from RFC
7481:

%                                        HTTP over TLS MUST be used to
% protect all client-server exchanges unless operational constraints
% make it impossible to meet this requirement.  [...]

It seems that we could use a different phrasing here that is more
commensurate with the requirements of STD 95.

</BK>

Scott Kelly commented in his review:

<SK>
Scott Kelly

From the abstract:
  This document specifies a method to find which Registration Data
  Access Protocol (RDAP) server is authoritative to answer queries for
  a requested scope, such as domain names, IP addresses, or Autonomous
  System numbers.  This document obsoletes RFC7484

Here is the security considerations section:

  "By providing a bootstrap method to find RDAP servers, this document
  helps to ensure that the end users will get the RDAP data from an
  authoritative source, instead of from rogue sources.  The method has
  the same security properties as the RDAP protocols themselves.  The
  transport used to access the registries can be more secure by using
  TLS [RFC8446], which IANA supports.

  Additional considerations on using RDAP are described in [RFC7481]."

Because this document is updating RFC7484, and because these security considerations are copied verbatim from that doc, I hesitate to raise my concern. Nonetheless, I think the assertion that this document "helps to ensure that the end users will get the RDAP data from an authoritative source, instead of from rogue sources." is questionable. I think the suggestion to use TLS helps, but I think it would be better to say something like this:

"This document specifies a method to find which RDAP server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. If this data is not authenticated, an adversary may inject data that redirects the user to a rogue RDAP server. A robust authentication method such as may be provided by TLS [RFC8446] SHOULD be utilized to protect against this.

Additional considerations on using RDAP are described in [RFC7481]."

I'm not attached to the precise wording, but I think implementers should be told what the risks are, and how to mitigate them. I don't think the current security considerations quite hit that aspiration.

</SK>

Furthermore, referring to SK text proposal, Benjamin Kaduk added:

<BK>
This is a good template for actual text to put in the document that covers
TLS usage and the need for it.  However, I think we may even be able to do
better than "TLS SHOULD be utilized", since (as I understand it) RFC 7481
has a requirement that "HTTP over TLS MUST be used to protect all
client-server exchanges unless operational constraints make it impossible
to meet this requirement."  So, we might end this text instead with
"A robust authentication method is provided by TLS [RFC8446], and
accordingly the use of TLS is required by RFC 7481 in the absence of
operational constraints that make use of TLS impossible; in such cases,
alternative authentication methods SHOULD be utilized to protect against
such risks.”
</BK>

I contacted IANA to ask them if there is any issue for them if we require HTTPS for accessing the registries. I’ve been told that:
- they currently serve both http and https, but they do HSTS
- I also get that comment:

<IANA>
While we do publish these resources over HTTPS, and by all means URLs can and should be specified with https:// URLs, we should generally avoid dictating specific technical choices that dictate the "maximum set" in RFCs unless they are critical to implementation. For example, what if there is a new secure dissemination technology that is more secure/performant/etc than HTTPS? If there is specific text that required it only be served over https would preclude publication via additional different means without necessarily issuing a superseding RFC. Would we have to discontinue other methods (like mirroring our data to IETF via rsync)?

To use an analogy, if we had a policy "Registration data must be published via the WHOIS protocol" versus "Registration data must only be published via the WHOIS protocol". The former specified a baseline requirement, the latter prohibits any other alternative technology, such as RDAP, being deployed.

A generalized solution, if the security is an underpinning requirement, is to use text like "The data should be published only through transports that provide guarantees of (authenticity/confidentiality/...), such as HTTPS".

Basically, it is better to state the requirements in the RFC conceptually rather than dictating contemporary technology choices, because the latter will constrain us later if we want to further evolve.
</IANA>

I concur with IANA that setting a specific secure transport may impose a limit in the future, however, I think HTTPS is probably a safe bet for some good time, enough until maybe a rev of this document would happen.

So I’m inclined to write something along: the registries MUST be provided ONLY through HTTPS (TLS RFC8446) transport.

Do the working group have any objection, comment? 

Regards, Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 28 Jan 2022 22:28:06 -0500

Hello,
 I haven’t seen any comment on the mailing list for my comments on the reviews regarding the IANA RDAP bootstrap registries being served by secure transport (aka https).
 However, I got a notice from IANA that they have changed from http to https to access the bootstrap registries. 

 Therefore,  -06, just published, now says: "the registries MUST be accessible only  through HTTPS (TLS RFC8446) transport.”

I will respond to the data tracker reviews from Benjamin and Scott in the next emails, related to this issue.

So to me, -06 is the final version ready for RFC editor queue.

Marc.

> Le 25 janv. 2022 à 18:58, Marc Blanchet <[email-masked]> a écrit :
> 
> Hello,