https://github.com/anewton1998/draft-regext-rdap-extensions/issues/55
>> Section 3.1, paragraph 1 >> account for transfers of resources between RIRs. Section 4.3 of [RFC7480] >> instructs servers to ignore unknown query parameters. As it relates to >> issuing URLs for redirects, servers MUST NOT blindly copy query parameters >> from a request to a redirect URL as query parameters may contain sensitive >> information, such as security credentials, not relevant to the target server >> of the URL. Following > The issue with this recommendation is that "unknown query parameter" is also > undefined. I think there is a difference between unknown and unsupported > parameters. [JS] Of course. But the term “unknown query parameter” is self-explanatory and inherently distinguishable from “unsupported query parameter” (known but not supported/implemented). The focus of this recommendation is on the former. [TH] I think clarifying this per Pawel's comment would be a good idea, even though the most reasonable reading is per your response here. > A parameter included in the RDAP Extensions Registry may be known to server > and still can be unsupported if the server does not implement given extension. [JS] Sorry, what does “A parameter included in the RDAP Extensions Registry” mean? > Following this line all parameters which are registered extension identifiers > or prefixed with register extension identifiers would be safe to forward > unless the nature of the parameter is either confidential or only related to > the context of the origin server. An example for the latter could be > page/sort/cursor from the rfc8977. It would be even better if registration of extension identifiers would specify if they are safe to be forwarded with redirect. This would also solve the issue with versioning eventually. [JS] That seems like a good idea. >> Section 3.1, paragraph 0 >> the advice in [RFC7480], servers SHOULD only place query parameters in >> redirect URLs when it is known by the origin server (the server issuing the >> redirect) that the target server (the server referenced by the redirect) can >> process the query parameter and the contents of the query parameter are >> appropriate to be received by the target. > As far as this may seem to be a valid recommendation I'm having hard time to > see how it would be practically implementable if the target of a redirect is > an RDAP server in other authority domain. [JS] This recommendation helps safely allow versioning parameter for search scenarios between a registry and a registrar that know each other well. As we know, redirects typically factor in for lookups. [AN] That's correct. It is difficult to implement and therefore not recommended. > Does it mean that the origin server would have to negotiate between what the > client requested and what the target server can support in terms of extensions etc. in order to generate a valid request with the query parameters that the server can process? Or, as consequence of 7480 4.3 shall we assume that the target server MUST ignore any unknown parameter so it is safe to assume that any parameter can be actually safely forwarded, even if related to unsupported extension? [TH] The points he raises here make me think that possibly the last sentence should be omitted altogether, since it could lead to divergent server behaviour and more problems for clients. In the unusual case where a query parameter should be included in a redirect, that could be documented as part of the relevant extension. Suggested updated text: ``` [RFC7480] describes the use of redirects in RDAP. Redirects are prominent in the discovery of authoritative RIR servers, as the process outlined in [RFC9224], which uses IANA allocations, does not account for transfers of resources between RIRs. Servers SHOULD NOT copy request query parameters from a request to a redirect URL, except where that is required or permitted by the specification or extension that defines the query parameter. This reduces the risk of exposure of authorisation credentials and similar. ``` [AN] A server MUST only copy a request parameter to a server in another authority if it knows that server is the proper target for the information of the query parameter, regardless of the extension. Otherwise sensitive data may leak. >> Section 4.1, paragraph 4 >> In general, extension authors should be mindful of situations requiring >> clients to directly handle redirects at the RDAP layer. > I think if such dependency exist the best way would be to define link > referrals rather than redirects. [JS] Fair point. > The client can be very aware of the processing needed to request RDAP > resource from another server. Maybe even structured redirect information > would be needed, where server, object class and name are broken down in > explicit way rather than relying on the client to digest it from the URL. > This would be a bigger change by defining all rdap specific web link types. [JS] Interesting idea. But as long as RDAP extension designers are aware of redirect pitfalls, this app layer-level redirect URLs handling can be avoided.
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
