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 <marc.blanc...@viagenie.ca> a écrit : > > 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
