Subject: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Apr 2013 10:51:21 -0700

Colleagues,

This message begins a two-week Working Group Last Call on
draft-ietf-weirds-rdap-sec.  Version 02 is current in the tracker:

https://datatracker.ietforg/doc/draft-ietf-weirds-rdap-sec

Last call will end on Friday, April 26.

Please review and comment on the draft, even if it is only to say on the
record "I have reviewed this document thoroughly and it looks good."  We
would like to have no fewer than five people report that they have taken a
look at the whole document and reported their findings, and will be
reticent to send it to the IESG without that.  We're also keen to hear from
people that have implemented the specification as to their views on
clarity, correctness, and completeness.

I will be the document shepherd for this one.

Thanks,

-MSK and Olaf, your co-chairs

---

From: Byron Ellacott <[email-masked]>
Date: Tue, 16 Apr 2013 05:08:04 +0000

Hello WG,

"I have reviewed this document thoroughly and it looks good."

 - The introduction does not refer to I-D.ietf-weirds-using-http, and perhaps should.
 - In 3.1.1, the [To be discussed: …] note should be removed.
 - 3.3 could reference -using–http on the use of 429 response codes, or vice versa.
 - 5 refers to RDAP as an "HTML-based protocol."  I believe the intent is to note that RDAP is expected to be used in an HTML presentation context at least some of the time, but the wording is not quite right there, I think.

These are minor points that should not stop this document from progressing.  Thanks to the authors for their work!

  Byron

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 13 April 2013 3:51 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

Colleagues,

This message begins a two-week Working Group Last Call on draft-ietf-weirds-rdap-sec.  Version 02 is current in the tracker:

Please review and comment on the draft, even if it is only to say on the record "I have reviewed this document thoroughly and it looks good."  We would like to have no fewer than five people report that they have taken a look at the whole document and reported their findings, and will be reticent to send it to the IESG without that.  We're also keen to hear from people that have implemented the specification as to their views on clarity, correctness, and completeness.

Thanks,

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 16 Apr 2013 17:12:21 +0000

Thanks for the feedback, Byron. Comments below.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Byron Ellacott
Sent: Tuesday, April 16, 2013 1:08 AM
To: [email-masked]
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

Hello WG,

> Perhaps. I don't have a problem with adding it.

 - In 3.1.1, the [To be discussed: ...] note should be removed.

> Yes, thanks for catching that.

 - 3.3 could reference -using-http on the use of 429 response codes, or vice versa.

> We already have a normative reference to RFC 6585. -using-http includes the same reference. I think we're good as long as the documents are consistent.

> s/As an HTML-based protocol/As a protocol using HTTP transport/? I'm open to  suggestions.

Scott

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 17 Apr 2013 01:23:18 +0000

Hi Scott,

From: <Hollenbeck>, Scott <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 17 April 2013 3:12 AM
To: Byron Ellacott <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

> s/As an HTML-based protocol/As a protocol using HTTP transport/? I’m open to  suggestions.

How about: "As a protocol likely to be used by services with an HTML presentation layer RDAP is susceptible…" ?

  Byron

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2013 10:18:56 -0000

> - 5 refers to RDAP as an "HTML-based protocol."  I believe the intent is to note that RDAP is
>expected to be used in an HTML presentation context ...

No, it's just a typo for HTTP-based protocol.

RDAP involves no HTML at all.  It includes HTTP requests and responses
that contain JSON.

It is possible to make RDAP-like queries that return HTML, if the
queries don't have the appropriate Accept:, but those are outside the
scope of RDAP.

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2013 10:30:38 -0000

>How about: "As a protocol likely to be used by services with an HTML presentation layer RDAP is

Please, no.  There is no HTML presentation layer or any other HTML in
RDAP.  It is 100% JSON all the time.

You don't need HTML for injection attacks:

http://rdap.example/domain/foo.com%22%3bdrop%20table%20domains%3b

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Apr 2013 10:56:46 +0000

From: Byron Ellacott [mailto:[email-masked]]
Sent: Tuesday, April 16, 2013 9:23 PM
To: Hollenbeck, Scott; [email-masked]
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

Hi Scott,

> s/As an HTML-based protocol/As a protocol using HTTP transport/? I'm open to  suggestions.

How about: "As a protocol likely to be used by services with an HTML presentation layer RDAP is susceptible..." ?

I don't know. I think the risk is more closely associated with HTTP transport than HTML presentation.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Apr 2013 10:59:46 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Levine
> Sent: Wednesday, April 17, 2013 6:19 AM
> To: [email-masked]

Yes, that's correct. It should be "HTTP".

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Apr 2013 13:19:43 +0000

While looking at the text in the Introduction section to address Byron's comment below I decided that I'd rather eliminate the references to the documents. The list will become incomplete if the core set changes (such as by adding a "search" document). Instead, I'd like to replace this text:

"The Registration Data Access Protocol (RDAP) core is specified in two documents: "Registration Data Access Protocol Lookup Format" [I-D.ietf-weirds-rdap-query] and "JSON Responses for the Registration Data Access Protocol (RDAP)" [I-D.ietf-weirds-json-response].  One goal of RDAP is to provide security services that do not exist in the WHOIS [RFC3912] protocol, including authentication, authorization, availability, data confidentiality, and data integrity.

This document describes each of these security services from the perspective of RDAP requirements and applicability.  Where applicable, informational references to requirements for a WHOIS replacement service [RFC3707] are noted."

with this:

"One goal of the Registration Data Access Protocol (RDAP) is to provide security services that do not exist in the WHOIS [RFC3912] protocol, including authentication, authorization, availability, data confidentiality, and data integrity.  This document describes how each of these services is applicable to RDAP and specifies requirements and approaches to provide the services.  Where applicable, informational references to requirements for a WHOIS replacement service [RFC3707] are noted."

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, April 16, 2013 1:12 PM
To: Byron Ellacott; [email-masked]
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

Scott

Hello WG,

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Apr 2013 11:06:45 -0700

I see what you're getting at, though it does seem odd to talk about RDAP
without a reference document explaining what exactly that is.

I recommend leaving the references in.  If we add search document(s) or
something else to the core set, this can be fixed during IETF LC or via RFC
Editor notes during IESG Evaluation.  Or, at a minimum, referencing a
subset of core documents is better than referencing none.

-MSK, document shepherd hat this time

On Wed, Apr 17, 2013 at 6:19 AM, Hollenbeck, Scott <[email-masked]
> wrote:

>  While looking at the text in the Introduction section to address Byron’s
> comment below I decided that I’d rather eliminate the references to the
> documents. The list will become incomplete if the core set changes (such as
> by adding a “search” document). Instead, I’d like to replace this text:***
> *
>
> ** **
>
> “The Registration Data Access Protocol (RDAP) core is specified in two
> documents: "Registration Data Access Protocol Lookup Format"
> [I-D.ietf-weirds-rdap-query] and "JSON Responses for the Registration Data
> Access Protocol (RDAP)" [I-D.ietf-weirds-json-response].  One goal of RDAP
> is to provide security services that do not exist in the WHOIS [RFC3912]
> protocol, including authentication, authorization, availability, data
> confidentiality, and data integrity.****
>
> ** **
>
> This document describes each of these security services from the
> perspective of RDAP requirements and applicability.  Where applicable,
> informational references to requirements for a WHOIS replacement service
> [RFC3707] are noted.”****
>
> ** **
>
> with this:****
>
> ** **
>
> “One goal of the Registration Data Access Protocol (RDAP) is to provide
> security services that do not exist in the WHOIS [RFC3912] protocol,
> including authentication, authorization, availability, data
> confidentiality, and data integrity.  This document describes how each of
> these services is applicable to RDAP and specifies requirements and
> approaches to provide the services.  Where applicable, informational
> references to requirements for a WHOIS replacement service [RFC3707] are
> noted.”****
>
> ** **
>
> Scott****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Hollenbeck, Scott
> *Sent:* Tuesday, April 16, 2013 1:12 PM
> *To:* Byron Ellacott; [email-masked]
>
> *Subject:* Re: [weirds] Working Group Last Call:
> draft-ietf-weirds-rdap-sec****
>
>  ** **
>
> Thanks for the feedback, Byron. Comments below.****
>
> ** **
>
> Scott****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Byron Ellacott
> *Sent:* Tuesday, April 16, 2013 1:08 AM
> *To:* [email-masked]
> *Subject:* Re: [weirds] Working Group Last Call:
> draft-ietf-weirds-rdap-sec****
>
> ** **
>
> Hello WG,****
>
> ** **
>
> "I have reviewed this document thoroughly and it looks good."****
>
> ** **
>
>  - The introduction does not refer to I-D.ietf-weirds-using-http, and
> perhaps should.****
>
> ** **
>
> > Perhaps. I don’t have a problem with adding it.****
>
> ** **
>
>  - In 3.1.1, the [To be discussed: …] note should be removed.****
>
> ** **
>
> > Yes, thanks for catching that.****
>
> ** **
>
>  - 3.3 could reference -using–http on the use of 429 response codes, or
> vice versa.****
>
> ** **
>
> > We already have a normative reference to RFC 6585. –using-http includes
> the same reference. I think we’re good as long as the documents are
> consistent.****
>
> ** **
>
>  - 5 refers to RDAP as an "HTML-based protocol."  I believe the intent is
> to note that RDAP is expected to be used in an HTML presentation context at
> least some of the time, but the wording is not quite right there, I think.
> ****
>
> ** **
>
> > s/As an HTML-based protocol/As a protocol using HTTP transport/? I’m
> open to  suggestions.****
>
> ** **
>
> Scott****
>
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Apr 2013 18:15:35 +0000

> it does seem odd to talk about RDAP without a reference document explaining what exactly that is.

This document will get stuck in a queue until the references can be resolved, but I see your point. I'll keep 'em in.

Scott

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Wednesday, April 17, 2013 2:07 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

I see what you're getting at, though it does seem odd to talk about RDAP without a reference document explaining what exactly that is.

I recommend leaving the references in.  If we add search document(s) or something else to the core set, this can be fixed during IETF LC or via RFC Editor notes during IESG Evaluation.  Or, at a minimum, referencing a subset of core documents is better than referencing none.
-MSK, document shepherd hat this time

On Wed, Apr 17, 2013 at 6:19 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:
While looking at the text in the Introduction section to address Byron's comment below I decided that I'd rather eliminate the references to the documents. The list will become incomplete if the core set changes (such as by adding a "search" document). Instead, I'd like to replace this text:

with this:

Scott

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, April 16, 2013 1:12 PM
To: Byron Ellacott; [email-masked]<mailto:[email-masked]>

Scott

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Byron Ellacott
Sent: Tuesday, April 16, 2013 1:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

Hello WG,

Scott

_______________________________________________
weirds mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/weirds

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Apr 2013 11:27:30 -0700

Reviewing as document shepherd:

Overall, this is in good shape.  Thanks to the editors for a job well
done.  What's below can be discussed on the list if anyone disagrees with
any of these points; rough consensus prevails.

Section 3 contains the first of many instances of a nit:

The "RFC4949 [RFC4949]" thing seems awkward.  Can we drop the first one?
(Same for various other instances of the same thing throughout.)  Section
3.4's reference to HTTP over TLS is a more useful syntax to me.

Section 3.1, the use of RFC2119 language around requirements was something
I'd not seen before.  I checked with Barry and he said it was proper, so
I'm not asking for any changes, but I just wanted to note that it might be
questioned during other evaluation phases.

Section 3.1, the APPROACH part, is the first indication that RDAP is built
upon HTTP, but it is indicated only if you follow the reference to
RFC2617.  I suggest either saying this explicitly in the prose here, or
adding a reference to our "using-http" draft in the Introduction section.

Section 3.1.1, the paragraph on OpenID points out that it's decentralized
twice.  Suggest striking the second one.  Also in that paragraph there's a
TBD item; has this been resolved?

Section 3.3, I don't think we can use RECOMMENDED in this way.  Suggest
replacing it with "advised".

Section 3.3, change "header" to "header field".

In Section 3.4, the first requirement avoids naming HTTP specifically while
the other two do.  I think it's fine to admit up front that we're going
with HTTP as the main transport mechanism (see above), so maybe that first
requirement can be dropped.

In Section 3.5, I think the point about data accuracy needs more emphasis
given how it's appeared in other contexts (e.g., ICANN).  It doesn't need
to be here; maybe a new section after Section 3, or a paragraph in Security
Considerations, would be a good place to talk about this for a sentence or
three.

Also in Section 3.5, isn't the first OPTION redundant to the second
REQUIREMENT?  Same with the second OPTION and the third REQUIREMENT.

In Section 5, I believe the MUST NOT belongs somewhere in Section 3 (maybe
a new subsection), or we should pick a non-normative expression if we want
to leave it there.

In Section 5, I suggest that we also remind readers (and a single sentence
should do it) that any vulnerabilities with respect to HTTP, HTTP AUTH,
HTTP over TLS, etc., also affect RDAP clients and servers.

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Apr 2013 12:34:45 +0000

Thanks for the comments Murray. More below.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Saturday, April 20, 2013 2:28 PM
To: [email-masked]
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec

Reviewing as document shepherd:
Overall, this is in good shape.  Thanks to the editors for a job well done.  What's below can be discussed on the list if anyone disagrees with any of these points; rough consensus prevails.
Section 3 contains the first of many instances of a nit:
The "RFC4949 [RFC4949]" thing seems awkward.  Can we drop the first one?  (Same for various other instances of the same thing throughout.)  Section 3.4's reference to HTTP over TLS is a more useful syntax to me.
> I always try to write using complete sentences that don't include the citation for needed references. Something like "blah blah as specified in [RFCXXXX]." isn't a complete sentence, though it's commonly used in many RFCs. I can make changes to use document titles as appropriate.
Section 3.1, the use of RFC2119 language around requirements was something I'd not seen before.  I checked with Barry and he said it was proper, so I'm not asking for any changes, but I just wanted to note that it might be questioned during other evaluation phases.
> It's an old debate.
Section 3.1, the APPROACH part, is the first indication that RDAP is built upon HTTP, but it is indicated only if you follow the reference to RFC2617.  I suggest either saying this explicitly in the prose here, or adding a reference to our "using-http" draft in the Introduction section.
> I'm adding the reference to the introduction.
Section 3.1.1, the paragraph on OpenID points out that it's decentralized twice.  Suggest striking the second one.  Also in that paragraph there's a TBD item; has this been resolved?
> I'll remove the second one, and yes, the TBD is being removed because the most recent version addresses the question.
Section 3.3, I don't think we can use RECOMMENDED in this way.  Suggest replacing it with "advised".

> OK.

> OK.
In Section 3.4, the first requirement avoids naming HTTP specifically while the other two do.  I think it's fine to admit up front that we're going with HTTP as the main transport mechanism (see above), so maybe that first requirement can be dropped.
> The purpose of the first requirement is to describe a need to protect plaintext credentials while in transit. It's not really about HTTP. I think it needs to stay, but if the purpose isn't clear can you suggest text to make it so?
In Section 3.5, I think the point about data accuracy needs more emphasis given how it's appeared in other contexts (e.g., ICANN).  It doesn't need to be here; maybe a new section after Section 3, or a paragraph in Security Considerations, would be a good place to talk about this for a sentence or three.

> I'll move it to the Security Considerations section, but I do think the ICANN focus has nothing to do with the protocol's security services. They're talking about data values being "truthful". That's not something we can guarantee.

Also in Section 3.5, isn't the first OPTION redundant to the second REQUIREMENT?  Same with the second OPTION and the third REQUIREMENT.
> Maybe they're not well ordered. The intention in the first case is to say "RDAP MAY include message integrity checks, and if it does, they MUST be fully specified...". Same basic flow for the second option and third requirement, but I agree that this last set doesn't flow very well. Either the requirement or the option can probably be removed. Which would you suggest?
In Section 5, I believe the MUST NOT belongs somewhere in Section 3 (maybe a new subsection), or we should pick a non-normative expression if we want to leave it there.
> Given "Non-repudiation services were also considered and ultimately rejected due to a lack of requirements", I don't like the idea of adding another section to 3. I'll remove the normative text.
In Section 5, I suggest that we also remind readers (and a single sentence should do it) that any vulnerabilities with respect to HTTP, HTTP AUTH, HTTP over TLS, etc., also affect RDAP clients and servers.
> Agreed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 22 Apr 2013 13:10:06 -0700

On Mon, Apr 22, 2013 at 5:34 AM, Hollenbeck, Scott <[email-masked]

>  > I always try to write using complete sentences that don’t include the
> citation for needed references. Something like “blah blah as specified in
> [RFCXXXX].” isn’t a complete sentence, though it’s commonly used in many
> RFCs. I can make changes to use document titles as appropriate.
>
Thanks.  I agree that I'm mostly expressing a personal preference on that
one, now that you mention it.

> ****
> In Section 3.4, the first requirement avoids naming HTTP specifically
> while the other two do.  I think it's fine to admit up front that we're
> going with HTTP as the main transport mechanism (see above), so maybe that
> first requirement can be dropped.
>
> > The purpose of the first requirement is to describe a need to protect
> plaintext credentials while in transit. It’s not really about HTTP. I think
> it needs to stay, but if the purpose isn’t clear can you suggest text to
> make it so?
>
Yeah, I see your point.  Let's try this on for size, and if you don't like
it, just let it go as-is:

Try dropping "HTTP" from the second requirement, and ending the third with
"...confidentiality methods that may be defined later."

> three.****
> > I’ll move it to the Security Considerations section, but I do think the
> ICANN focus has nothing to do with the protocol’s security services.
> They’re talking about data values being “truthful”. That’s not something we
> can guarantee.
>

Totally agree.  I think I'm trying to head off the idea that some ICANN
reader might look at this and say we forgot about or misunderstood the
"truthful" issue; I'd rather we say it's simply not possible for this
protocol (or, quite possibly, any protocol) to make positive assertions
about the truth of the data, and such things shouldn't be inferred by
clients or implementers.

(Stephen Colbert's voice keeps coming to me when I type that word.)

> REQUIREMENT?  Same with the second OPTION and the third REQUIREMENT.****
>
> > Maybe they’re not well ordered. The intention in the first case is to
> say “RDAP MAY include message integrity checks, and if it does, they MUST
> be fully specified…”. Same basic flow for the second option and third
> requirement, but I agree that this last set doesn’t flow very well. Either
> the requirement or the option can probably be removed. Which would you
> suggest?
>
Personally, I would remove the options.  To me they don't add anything;
saying RDAP or a layer below it MUST provide those facilities (even if
they're optional at those layers) seems adequate to me.  But since you see
what I'm getting at, I'll leave it to your discretion.

> to leave it there.****
> > Given “Non-repudiation services were also considered and ultimately
> rejected due to a lack of requirements”, I don’t like the idea of adding
> another section to 3. I’ll remove the normative text.
>
WFM.

Thanks!

-MSK

---

From: Peter Koch <[email-masked]>
Date: Wed, 24 Apr 2013 10:57:54 +0200

> Please review and comment on the draft, even if it is only to say on the

I have read the document and I do not believe it is ready to be sent to the IESG.

Assuming the "Intended status: Standards Track" reflects current intentions,
I fail to recognize the protocol specifications in the draft.  While section two
refers to RFC 2119 wording, the draft relies upon "REQUIREMENT", "OPTION"
and "APPROACH" or even "POSSIBLE APPROACH".  The first two frame mandatory or
optional requirements (so they address properties of the protocol rather than the
implementation, in which case the normative language semantics are shifted).
The latter I am not sure how to interpret. What nature is an "APPROACH" compared
to a suggestion (noting well the ambiguity of strength in that word, too).
Who is the addressee for this? Is it the implementer or the operator?

On specific security "services":

o "3.3 availability" is clearly operational guidance rather than a protocol spec

o "3.4 data confidentiality" mentions data but mostly talks about protecting
  the credentials (avoid clear text passwords).  Is it intended to cover both?

o "3.5 data integrity" states requirements (again: protocol or ops?), but then
  concludes with TLS "MAY" "if the policy of the server operator requires message
  integrity" to end with a normative language requirement for the protocol:
  "RDAP MUST NOT preclude support for this feature in the future".  I'd not know
  how to evaluate an specification/implementation/service against this.

-Peter

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 24 Apr 2013 11:34:53 +0000

> Behalf Of Peter Koch
> Sent: Wednesday, April 24, 2013 4:58 AM
> To: IETF WEIRDS WG

I'll leave the intended status and protocol vs. ops meta questions for Murray and Olaf.

No, the draft does not rely upon "REQUIREMENT", "OPTION", and "APPROACH". Those words have no normative meaning. If that's somehow confusing I can use "Requirement", "Option", and "Approach" (modulo elimination of some of these as discussed in a thread to address Murray's comments). I used upper case only to emphasize those areas of text.

The "approach" text is intended to describe a way to meet the requirement. The guidance presented is intended for both implementers and operators as appropriate.

> o "3.3 availability" is clearly operational guidance rather than a

True. Operational guidance is often included in protocol specifications.

>   the credentials (avoid clear text passwords).  Is it intended to

It's intended to address all known requirements for "data confidentiality" as defined in RFC 4949. The only requirement I could identify is the one to protect credentials, which qualify as "data".

>   how to evaluate an specification/implementation/service against this.

Agreed, "MUST NOT preclude support for this feature in the future" isn't something that can be addressed by an implementer. It's a requirement for specification writers. How such guidance is provided is another question I'll defer to Murray and Olaf.

Scott

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 24 Apr 2013 13:06:07 -0400

On 4/24/2013 7:34 AM, Hollenbeck, Scott wrote:
>> ...
Some of the response data may be confidential. Isn't this the main 
reason for using authentication, for special classes of users such as 
law enforcement? Any non-public data that requires authentication should 
only be returned with protection for confidentiality.

-Ernie

---

From: Peter Koch <[email-masked]>
Date: Wed, 24 Apr 2013 19:19:01 +0200

Scott,

thanks for your instant reply.

> I'll leave the intended status and protocol vs. ops meta questions for Murray and Olaf.

fair enough.

> No, the draft does not rely upon "REQUIREMENT", "OPTION", and "APPROACH". Those words have no normative meaning. If that's somehow confusing I can use "Requirement", "Option", and "Approach" (modul…

At least that would eliminate my confusion regarding the normative (or not so) nature of those terms.

> The "approach" text is intended to describe a way to meet the requirement. The guidance presented is intended for both implementers and operators as appropriate.

This, however, I believe would benefit from an introduction in section 2.
That said, and recognizing your first response above, I have a hard time seeing this
in standards track.

> True. Operational guidance is often included in protocol specifications.

That is correct, but the use of normative language could be reduced a bit.
``A thorough reading of RFC 4732 [RFC4732] is RECOMMENDED'' is one such case.
By the way, RFC 4732 is Informational and (rightfully, given the above)
classified as normative reference.  That's a downref.

> It's intended to address all known requirements for "data confidentiality" as defined in RFC 4949. The only requirement I could identify is the one to protect credentials, which qualify as "data".

Agreed, in an abstract sense.  What I was trying to highlight is that
the "RDAP" distinguishes between credentials and data (objects) and that
the document might benefit from a more explicit explanation which of those
(or even both) is covered.

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 10:48:29 -0700

Hey Peter,

> > I'll leave the intended status and protocol vs. ops meta questions for

I'm consulting with our ADs on this question now.  I'll get back to the WG
with the result of that inquiry.

> classified as normative reference.  That's a downref.

Yes.  The shepherd writeup already calls out this downref, as required.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 12:16:39 -0700

> with the result of that inquiry.

I talked to Pete about this.  He thinks this work qualifies as an
Applicability Statement since it explains how to achieve certain
capabilities when using RDAP that are important to RDAP clients and servers
but are not inherent parts of RDAP.  Accordingly, Proposed Standard is the
correct status to request.

However, he did highlight that there's a bit of work we need to do here to
clarify some of the messages the document is giving.  For example, as Peter
Koch pointed out, the APPROACH stuff was a little confusing to the eye for
people that haven't been tracking it all along, and he asked some questions
about our use of MUST in conjunction with them.  Pete suggests a few things:

a) add to Section 2 definitions of how REQUIREMENT, APPROACH and POSSIBLE
APPROACH are used in later sections; I took them to mean "Given these
requirements, here's one or more ways to achieve them", so some prose to
that effect would suffice

b) saying "REQUIREMENT: RDAP MUST include an authentication framework", for
example, is technically incorrect because the authentication framework is
clearly part of HTTP and not part of RDAP, so we should be similarly clear
that the requirement is on the chosen transport mechanism, not on RDAP
itself

c) REQUIREMENT and MUST appear to be redundant

d) APPROACH and MUST appear to conflict

I note that all of this is stylistic stuff; the procedural and substantive
content issues all seem to be in order.

-MSK

---

From: SM <[email-masked]>
Date: Wed, 24 Apr 2013 23:25:55 -0700

>I have read the document and I do not believe it is ready to be sent 

I read draft-ietf-weirds-rdap-sec.  It's highly unusual as an 
intended Proposed Standard.    The draft looks like a RFP instead of 
a specification for the Standards Track.  I might be asked why it 
should not be on the Standards Track.  Well, there is a missing 
normative reference to RFC 6919. :-)

Regards,
-sm

---

From: Peter Koch <[email-masked]>
Date: Thu, 25 Apr 2013 09:36:50 +0200

> correct status to request.

I truly admire Pete for opening this rarely explored path.  Even as an AS (as per
RFC 2026, 3.2) the document needs more work.  There is a mix of requirements
for the protocol itself (not appropriate for an AS), requirements for implementers and
guidance to operators, some of which lacks clarity or strength that I'd at least
expect in an AS.

> that effect would suffice

agree with the former, not necessarily with the latter.

> content issues all seem to be in order.

The strength and normative-ness of the statements expressed isn't a matter
of style.  I have serious concerns regarding the clarity of the specification
(or, say applicability statement) when it comes to either compliance or
interoperability issues.  What I expect is protocol, what I think I'm
seeing is a product or service description.

-Peter

---

From: SM <[email-masked]>
Date: Thu, 25 Apr 2013 01:35:03 -0700

Agreed.

   'If the "basic" scheme is used another protocol (such as
    HTTP Over TLS [RFC2818]) MUST be used to protect the client's
    credentials from disclosure while in transit (see Section 3.4).'

I do not understand this requirement as it basically says that I can 
pick another protocol (which is unspecified) and things should work fine.

   "The data confidentiality methods used by RDAP MUST be fully specified
    and available to existing HTTP clients and servers."

The IETF is asking some external entity to specify data 
confidentiality methods for HTTP clients and servers.  It sounds like 
the IETF is incompetent when it comes to producing specifications for 
HTTP servers and clients.

draft-ietf-weirds-rdap-sec-02 is severely under-specified.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 07:10:15 -0700

On Thu, Apr 25, 2013 at 1:35 AM, SM <[email-masked]> wrote:

> I do not understand this requirement as it basically says that I can pick
> another protocol (which is unspecified) and things should work fine.
>

"basic" doesn't protect credentials from being snooped.  If that's
important, you have to add another layer that does.  Is that an incorrect
thing to say?

> The IETF is asking some external entity to specify data confidentiality
> methods for HTTP clients and servers.  It sounds like the IETF is
> incompetent when it comes to producing specifications for HTTP servers and
> clients.
>

That's not what this says to me.  I read it as: RDAP is built atop existing
data confidentiality methods rooted in HTTP.  Is that inappropriate?

Would you care to propose alternative text or some other solution?

-MSK

---

From: SM <[email-masked]>
Date: Thu, 25 Apr 2013 07:32:22 -0700

Hi Murray,
At 07:10 25-04-2013, Murray S. Kucherawy wrote:
>important, you have to add another layer that does.  Is that an 
>incorrect thing to say?

There is a MUST" in the sentence.  There is usually be a good reason 
for having that key word.  If it is not important it does not make 
sense to have that key word.

>That's not what this says to me.  I read it as: RDAP is built atop 
>existing data confidentiality methods rooted in HTTP.  Is that inappropriate?

There is also a "MUST" in the sentence.  What's inappropriate in my 
opinion is the usage of "MUST".  I read the usage of the "MUST" as:

    The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate
    requirements that are needed to meet formal review criteria (e.g.,
    mandatory-to-implement security mechanisms), when these mechanisms
    are too inconvenient for implementers to actually implement.

>Would you care to propose alternative text or some other solution?

I suggest publishing the document as Informational as the intended 
status is not important to the working group.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 08:26:08 -0700

On Thu, Apr 25, 2013 at 7:32 AM, SM <[email-masked]> wrote:

> There is a MUST" in the sentence.  There is usually be a good reason for
> having that key word.  If it is not important it does not make sense to
> have that key word.

I've consulted with two ADs on this question and neither objected to this
use.  Use of RFC2119 language to describe requirements is typical in
applicability statements as a way of describing what one needs to do to
provide some capability that's not part of the core specification.
RFC6647, for example, describes ways to apply SMTP to perform greylisting;
there's normative language in there that describes the way to create a
capability but not enact a protocol.

>    are too inconvenient for implementers to actually implement.

I don't think that's a fair characterization.

-MSK