Subject: [weirds] Stephen Farrell's No Objection on draft-ietf-weirds-rdap-sec-10: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 30 Oct 2014 06:52:48 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-weirds-rdap-sec-10: 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.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 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.

---

From: Andy Newton <[email-masked]>
Date: Thu, 30 Oct 2014 14:20:24 +0000

> real need to not use TLS for weirds ever?

In addition to what John Levine said regarding the interop issues with TLS,

1) The information to be served over RDAP is served over Whois today, and that has no protections at all.  Since Whois will remain with us for sometime, a MUST TLS can impose adoption issues for some service operators where they don’t have those issues with Whois. Which leads to item #2...

2) As a service operator, we frequently get spikes. If we had to always serve this data over TLS, there is a good chance we could not handle the load. Those spikes aren’t always predictable. Why is it difficult to handle this? See #3…

3) It’s almost 2015, and we should have load balancers that can handle TLS. But when you want those same load balancers to work with IPv6, not so much. While the vendors claim they can do this, their glossyware and reality do not match. So given the choice between IPv6 connectivity and always using TLS, we have to go with IPv6.

-andy