Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec-00

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 1 Oct 2012 13:00:54 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of SM
> Sent: Thursday, September 27, 2012 5:50 PM
> To: [email-masked]
> Subject: [weirds] Comments on draft-ietf-weirds-rdap-sec-00
> 
> Hello,
> 
> These comments are on draft-ietf-weirds-rdap-sec-00.  Please note that
> this is not a review.
> 
> In the Introduction Section:
> 
>    "One goal of RDAP is to provide security services that do not exist
>     in the WHOIS protocol"
> 
> One of the questions that may be asked is why is security not part of
> the protocol.

I can add text that explains how WHOIS use has changed over time, but I don't want to try to guess at the motives of the original author.

> RFC 4949 is more of a glossary.  If I recall correctly, it has been
> used for some specification.  I am not sure whether it is a correct
> reference.

It's cited as an informative reference because it defines the security services. Without the reference I would have to define each one. That seems silly given that we already have 4949.

> In Section 3.5:
> 
>    "TBD: does it make sense to talk about proof of integrity and data
>     origin authentication for responses?"
> 
> I would say yes.  I suggest forgetting the law enforcement angle and
> look at this in terms of data integrity.  As a quick comment, I think
> that it may be easier to avoid non-repudiation.  It may be easier to
> focus on "securing" the protocol instead of looking at this from a data
> point of view.

I think you're right about the need. One thought I had was to approach each service from a use case or requirement perspective. Is there a use case that requires confidentiality? Authentication? Availability? Integrity? Non-repudiation? If that answer to any of these questions is "no" then it's probably safe to say that the service isn't needed.

Scott

---

From: SM <[email-masked]>
Date: Mon, 01 Oct 2012 08:04:35 -0700

Hi Scott,
At 06:00 01-10-2012, Hollenbeck, Scott wrote:
>I can add text that explains how WHOIS use has changed over time, 
>but I don't want to try to guess at the motives of the original author.

Sorry for not being clear.  I meant why is security not part of RDAP.

Regards,
-sm

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 1 Oct 2012 16:43:38 +0000

> From: SM [mailto:[email-masked]]
> Sent: Monday, October 01, 2012 11:05 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: RE: [weirds] Comments on draft-ietf-weirds-rdap-sec-00
> 
> Hi Scott,
> >I can add text that explains how WHOIS use has changed over time, but
> I
> >don't want to try to guess at the motives of the original author.
> 

Now I'm confused. Security *is* part of RDAP. What have you seen (or not seen) to suggest otherwise?

Scott

---

From: SM <[email-masked]>
Date: Mon, 01 Oct 2012 10:04:59 -0700

Hi Scott,
>not seen) to suggest otherwise?

I read draft-ietf-weirds-rdap-query-00.  I commented on the security 
aspect in the message at 
http://www.ietf.org/mail-archive/web/weirds/current/msg01656.html

Regards,
-sm

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 1 Oct 2012 17:15:58 +0000

> Sent: Monday, October 01, 2012 1:05 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> aspect in the message at http://www.ietf.org/mail-
> archive/web/weirds/current/msg01656.html

...and Andy and I both replied to that. Are you suggesting that something needs to be added to rdap-sec or rdap-query? If so, what?

Scott

---

From: SM <[email-masked]>
Date: Mon, 01 Oct 2012 10:45:25 -0700

Hi Scott,
At 10:15 01-10-2012, Hollenbeck, Scott wrote:
>...and Andy and I both replied to that. Are you suggesting that 
>something needs to be added to rdap-sec or rdap-query? If so, what?

I don't have a strong opinion about any of this in the context of 
this WG.  If the WG is designing a new protocol, the question which 
may be asked is whether security is part of the protocol.  As 
rdap-sec is optional, it can be argued that it is not part of the protocol.

Regards,
-sm

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 1 Oct 2012 17:50:52 +0000

> Sent: Monday, October 01, 2012 1:45 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> I don't have a strong opinion about any of this in the context of this
> WG.  If the WG is designing a new protocol, the question which may be
> asked is whether security is part of the protocol.  As rdap-sec is
> optional, it can be argued that it is not part of the protocol.

Optional? How so? Eventually it should be added to both the query and response documents as a normative reference.

Scott

---

From: SM <[email-masked]>
Date: Mon, 01 Oct 2012 11:26:18 -0700

Hi Scott,
At 10:50 01-10-2012, Hollenbeck, Scott wrote:
>Optional? How so? Eventually it should be added to both the query 
>and response documents as a normative reference.

A normative reference to a security proposal does not make security 
non-optional.  The question is addressed through requirements.  I 
don't see any such requirements in the drafts at the moment.  It's 
not a problem as the drafts are -00.

Regards,
-sm

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 1 Oct 2012 18:52:03 +0000

> Sent: Monday, October 01, 2012 2:26 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> >Optional? How so? Eventually it should be added to both the query and
> >response documents as a normative reference.
> 
> non-optional.  The question is addressed through requirements.  I don't
> see any such requirements in the drafts at the moment.  It's not a
> problem as the drafts are -00.

Per section 1.1 of RFC 3967, a normative reference "specifies a document that must be read to fully understand or implement the subject matter in the new RFC, or whose contents are effectively part of the new RFC, as its omission would leave the new RFC incompletely specified". That doesn't sound like "optional".

I agree that we need text in the query and response drafts to describe needed security services.

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Oct 2012 21:31:29 -0700

On Mon, Oct 1, 2012 at 11:26 AM, SM <[email-masked]> wrote:
> non-optional.  The question is addressed through requirements.  I don't see
> any such requirements in the drafts at the moment.  It's not a problem as
> the drafts are -00.

I can see what you're getting at, but I'm not sure there's only one
way to resolve this.

A complete protocol specification can span many documents, without
automatically meaning that only the base document (assuming there is
one) defines the protocol itself.  MIME comes to mind, plus the
now-seven-part HTTP 1.1 revision that's being developed in another
working group.  Moreover, even WHOIS is itself a complete protocol
even though it is totally insecure; you could run it over port 443 if
you want security, but it's functional without (with the caveat that
there are no security provisions in it).  SMTP is ubiquitous but also
famously insecure; STARTTLS is defined in an extension document.

I think it's fine to produce a document defining RDAP that includes no
security provisions at all, so long as it says there are none, and
also says something like "If you have any of the usual security
requirements for your application of this, go read this other document
which tells you how to do so."

-MSK