Skip to main content

Security Services for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-rdap-sec-12

Yes

(Pete Resnick)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)

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

Pete Resnick Former IESG member
Yes
Yes (for -10) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2014-12-22) Unknown
Thanks for handling my discuss and comment points.
Barry Leiba Former IESG member
No Objection
No Objection (2014-10-28 for -10) Unknown
-- 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
Benoît Claise Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2014-11-25 for -11) Unknown
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 Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (2014-10-30 for -10) Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-10-30 for -10) Unknown

- 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.
Ted Lemon Former IESG member
(was Discuss) No Objection
No Objection (2014-10-30 for -10) Unknown
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.