Benjamin Kaduk has entered the following ballot position for status-change-rdap-to-internet-standard-01: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/status-change-rdap-to-internet-standard/ ---------------------------------------------------------------------- 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. _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
