Advancing the Registration Data Access Protocol (RDAP) to Internet Standard
status-change-rdap-to-internet-standard-01

The following approval message was sent
From: The IESG
To: IETF-Announce 
Cc: The IESG ,
    draft-ietf-weirds-rdap-sec@ietf.org,
    draft-ietf-weirds-using-http@ietf.org,
    iana@iana.org,
    regext@ietf.org,
    rfc-editor@rfc-editor.org,
    shollenbeck@verisign.com,
    weirds-chairs@ietf.org
Subject: Protocol Action: Security Services for the Registration Data Access Protocol (RDAP) to Internet Standard

The IESG has approved changing the status of the following document:
- Security Services for the Registration Data Access Protocol (RDAP)
  (rfc7481) to Internet Standard

This protocol action is documented at:
https://datatracker.ietf.org/doc/status-change-rdap-to-internet-standard/

A URL of the affected document is:
https://datatracker.ietf.org/doc/rfc7481/

Status Change Details:

RFCs 7480 ("HTTP Usage in the Registration Data Access Protocol (RDAP)")
and 7481 ("Security Services for the Registration Data Access Protocol
(RDAP)") were published as Proposed Standards in March, 2015, along with
RFCs 7482 ("Registration Data Access Protocol (RDAP) Query Format"), 7483
("JSON Responses for the Registration Data Access Protocol (RDAP)"), and
7484 ("Finding the Authoritative Registration Data (RDAP) Service"). RFCs
7482 and 7483 have been updated to address known errata and necessary
clarifications based on implementation experience, and the 7482bis and
7483bis Internet-Draft documents are on track for approval as Internet
Standards. A revision of RFC 7484 is being considered by the REGEXT
working group for submission as Internet Standard.

RDAP is fully deployed and operational at all five Regional Address
Registries. RDAP implementation and operation is a contractual requirement
for all ICANN-accredited domain name registries and 2,370 registrars. The
IANA "Bootstrap Service Registry for Domain Name Space" describes 820 unique
RDAP base URLs that are are associated with several thousand generic
top-level and country code domain name RDAP servers that are operated by
domain name registries.

While it is a stated goal in RFC 7480 that "RDAP is a successor protocol to
the very old WHOIS protocol," WHOIS remains widely deployed and in active
use, and is likely to be so for some time.  This action addresses only the
maturity of RDAP itself, and makes no statement nor implication about WHOIS.

RFCs 7480 and 7481 have no verified errata, and no known issues that require
that the documents be revised prior to a change in status from Proposed
Standard to Internet Standard. The RFC 6410 requirements for "at least two
independent interoperating implementations with widespread deployment and
successful operational experience" and "no unused features in the
specification that greatly increase implementation complexity" have been
met. This status change, therefore, requests a change in status for RFCs
7480 and 7481 from Proposed Standard to Internet Standard.

Personnel

  Barry Leiba is the responsible Area Director.

The following approval message was sent
From: The IESG
To: IETF-Announce 
Cc: The IESG ,
    draft-ietf-weirds-rdap-sec@ietf.org,
    draft-ietf-weirds-using-http@ietf.org,
    iana@iana.org,
    regext@ietf.org,
    rfc-editor@rfc-editor.org,
    shollenbeck@verisign.com,
    weirds-chairs@ietf.org
Subject: Protocol Action: HTTP Usage in the Registration Data Access Protocol (RDAP) to Internet Standard

The IESG has approved changing the status of the following document:
- HTTP Usage in the Registration Data Access Protocol (RDAP)
  (rfc7480) to Internet Standard

This protocol action is documented at:
https://datatracker.ietf.org/doc/status-change-rdap-to-internet-standard/

A URL of the affected document is:
https://datatracker.ietf.org/doc/rfc7480/

Status Change Details:

RFCs 7480 ("HTTP Usage in the Registration Data Access Protocol (RDAP)")
and 7481 ("Security Services for the Registration Data Access Protocol
(RDAP)") were published as Proposed Standards in March, 2015, along with
RFCs 7482 ("Registration Data Access Protocol (RDAP) Query Format"), 7483
("JSON Responses for the Registration Data Access Protocol (RDAP)"), and
7484 ("Finding the Authoritative Registration Data (RDAP) Service"). RFCs
7482 and 7483 have been updated to address known errata and necessary
clarifications based on implementation experience, and the 7482bis and
7483bis Internet-Draft documents are on track for approval as Internet
Standards. A revision of RFC 7484 is being considered by the REGEXT
working group for submission as Internet Standard.

RDAP is fully deployed and operational at all five Regional Address
Registries. RDAP implementation and operation is a contractual requirement
for all ICANN-accredited domain name registries and 2,370 registrars. The
IANA "Bootstrap Service Registry for Domain Name Space" describes 820 unique
RDAP base URLs that are are associated with several thousand generic
top-level and country code domain name RDAP servers that are operated by
domain name registries.

While it is a stated goal in RFC 7480 that "RDAP is a successor protocol to
the very old WHOIS protocol," WHOIS remains widely deployed and in active
use, and is likely to be so for some time.  This action addresses only the
maturity of RDAP itself, and makes no statement nor implication about WHOIS.

RFCs 7480 and 7481 have no verified errata, and no known issues that require
that the documents be revised prior to a change in status from Proposed
Standard to Internet Standard. The RFC 6410 requirements for "at least two
independent interoperating implementations with widespread deployment and
successful operational experience" and "no unused features in the
specification that greatly increase implementation complexity" have been
met. This status change, therefore, requests a change in status for RFCs
7480 and 7481 from Proposed Standard to Internet Standard.

Personnel

  Barry Leiba is the responsible Area Director.

[Ballot comment]
If the documents were being opened up I would have some comments on
their content, but it's not really clear that there are any truly needed
changes.  It's also unclear that the topics are such that adding words
to the status-change document would help, either.

The main point that struck me is that 7480 and 7481 seem to give
qualitatively different pictures of the status of TLS usage for RDAP.
In RFC 7480 we see that "a client issues an HTTP (or HTTPS) query" and,
admittedly, that entities MUST support https, but no statement about
whether the actual *use* of HTTPS is recommended.  RFC 7481, on the
other hand, has the language about "HTTP over TLS MUST be used [...]
unless operational constraints make it impossible" that we would expect
from an Internet Standard (as well as unqualified requirements in
specific scenarios that require the protection TLS provides).

There is also a fair bit of text in RFC 7481 that is in some sense
"speculative", for example regarding the use of federated
authentication/authorization technologies and object-level cryptographic
protections on responses.  While this does not really reflect an "unused
protocol feature" that would need to be removed in order to advance to
Internet Standard, it is perhaps a little distracting when that's what
one's going for.

(I guess one thing that might be useful to add to the status-change
document is if there's any updates about the
implementation/specification status for such object-security or
federation techniques.)

If we were opening the documents I would ask for additional discussion
of the flaws and weaknesses of HTTP Basic authentication (and perhaps a
demotion of its recommended-level).

Two other comments on the text of RFC 7481, neither of which is likely
to require a text change, but still seem worth noting:

(Both quoted snippets appear in Section 3.2)

  This section describes security authentication mechanisms and the
  need for authorization policies to include them.  It describes
  requirements for the implementations of clients and servers but does
  not dictate the policies of server operators.  For example, a server
  operator with no policy regarding differentiated or tiered access to
  data will have no authorization mechanisms and will have no need for
  any type of authentication.  [...]

As a security practitioner I'm always wary of absolute statements like
this; for example, a server that does not have tiered access to data
might still benefit from authenticating clients for use in logging, and
post-facto inquiries into who had accessed certain data.

  Note that OAuth and OpenID do not consistently require data
  confidentiality services to protect interactions between providers
  and consumers.  HTTP over TLS [RFC2818] can be used as needed to
  provide protection against man-in-the-middle attacks.

The intent of this statement is perhaps a bit unclear.  It is a factual
statement that they do not always require as part of the protocol
confidentiality services, though it's arguably unclear whether that was
a wise decision or remains so.  Furthermore, I believe that the
generally accepted best practices for OAuth and OpenID have changed
since the time this text was written, with documents like
draft-ietf-oauth-security-topics providing carefully reasoned guidance
born of painful experience.

The following Last Call announcement was sent out (ends 2021-02-24):

From: The IESG
To: IETF-Announce
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call: Advancing the Registration Data Access Protocol (RDAP) to Internet Standard


The IESG has received a request from the REGEXT working group
to make the following status changes:

- RFC7480 from Proposed Standard to Internet Standard
    (HTTP Usage in the Registration Data Access Protocol (RDAP))

- RFC7481 from Proposed Standard to Internet Standard
    (Security Services for the Registration Data Access Protocol (RDAP))

The supporting document for this request can be found here:

https://datatracker.ietf.org/doc/status-change-rdap-to-internet-standard/

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

The affected documents can be obtained via
https://datatracker.ietf.org/doc/rfc7480/
https://datatracker.ietf.org/doc/rfc7481/

IESG discussion of this request can be tracked via
https://datatracker.ietf.org/doc/status-change-rdap-to-internet-standard/ballot/