Security Services for the Registration Data Access Protocol (RDAP)
RFC 7481

Note: This ballot was opened for revision 09 and is now closed.

Search Mailarchive

(Pete Resnick) Yes

(Jari Arkko) No Objection

Alia Atlas No Objection

(Richard Barnes) No Objection

Comment (2014-10-30 for -10)
I support Alissa's comments about privacy.  It would be good to clarify those considerations and provide some good recommendations about what not to send.

Benoit Claise No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2014-12-22)
Thanks for handling my discuss and comment points.

Spencer Dawkins No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-10-30 for -10)

- I strongly support Aliss's discuss on privacy. That would be
even more important should registrars/registries in future
require that personally identifying information be available
for all registrants, which I believe is a policy that at least
some are arguing for.

- Isn't it sad that HTTP basic and digest still have to be the
MTIs here for client auth. (I would suggest HOBA [1] but that's
not quite done, being just finished WGLC, and would be
self-serving, though it would be far better than basic or
digest;-)

   [1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba-05

- Why not just say "TLS MUST be used" in all cases? Is there a
real need to not use TLS for weirds ever?

- TLS client auth - I think you could easily make this MTI (to
implement, not to use) as its basically there in most
codebases.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2014-10-28 for -10)
-- Section 3.1 --

   This section describes security authentication mechanisms and their
   need for implementation by authorization policies.

It took me a few readings to get what I think you mean.  I think you mean this:
NEW
   This section describes security authentication mechanisms and the
   need for authorization policies to include them.
END

(Ted Lemon) (was Discuss) No Objection

Comment (2014-10-30 for -10)
Barry has pointed out that there is a way to trigger the clients to send credentials using a login link, so that addresses my concern.   I didn't actually see that explicitly mentioned in the document, but Pete says it's there so I'll take his word for it.

Kathleen Moriarty (was Discuss) No Objection

Comment (2014-11-25 for -11)
Thanks for your work on this and the other Weirds drafts and adding in my requested text on privacy options to the response draft (Alissa's in this draft) as well as addressing my other discuss points (TLS BCP, etc.).  The new sections are helpful to explain privacy and access control options (3.1) that have been added in this new protocol.



Section 3.1
As an FYI (not asking for anything to be done here except to participate in HTTPAuth last calls) - HTTP Digest and Basic just went through a revision and are just about done.  There are a few minor updates and the security considerations in the updated documents spell out the remaining issues.  Although these are the solutions for HTTP Auth, most people don't rely on it and use other methods, so we don't have implementations of better options.  There are a few other options in the HTTPAuth WG about to go to IETF last call or are WG drafts.  If you are going to rely on HTTPAuth methods, maybe there should be a push for the improved options from the WEIRDS WG - at least pitching in to review during last calls.  
https://datatracker.ietf.org/wg/httpauth/documents/

(Martin Stiemerling) No Objection