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.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
