Subject: [apps-discuss] Apps Area review of draft-ietf-weirds-json-response-10

From: Tim Bray <[email-masked]>
Date: Mon, 27 Oct 2014 11:27:38 -0700

I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see http://trac.tools.ietf.org/area
/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:draft-ietf-weirds-json-response-10
Title: JSON Responses for the Registration Data Access Protocol (RDAP)
Reviewer:Tim Bray
Review Date: October 27, 2014

Summary: this is pretty clean, and generously equipped with examples, which
is a good thing.  I think the specification of extensibility is
unacceptably messy but could be cleaned up easily.

However, I think the fact that there are no Security Considerations is very
troubling.

Major issues:

10.1 The only security consideration in a protocol definition is the basic
JSON stuff?  Really?  DNS vulnerabilities can be horribly damaging to the
Internet; it’s hard to believe you can just skip over security
considerations.  If I were on the IESG I’d be having heartburn.

Minor issues:

Construction of new values with underscores.  A few things:

1. Why not give these things a name such a “foreign members” or “foreign
objects”, short for “JSON markup that is not specified in this document”.
Might make them easier to talk about.
2. You should also explicitly say that “this document and its successors
will never define an member name containing an underscore”
3. Why don’t you restrict extensibility to members of objects with names
not defined in this spec? Practically speaking, that’s the only place
they’re apt to turn up. Being specific would make the whole thing crisper.

In section 2.1, 2nd-last para “Clients processing JSON responses need to be
prepared for values specified in this document to be absent from a
response”. Uh, do you man that ALL values specified in this document are
optional, none are compulsory?  This is super-important and should be
called out in its own section.  Reading through the text, there seem to be
several instances of some members being optional, others non-optional.  So
I’m actually not sure what this language is trying to say.

4.2 “All other JSON values are OPTIONAL”.  I don’t understand a value being
optional? Does it mean the value can be an empty string?  Does it mean that
the name/value member can be omitted? If true, doesn’t that imply that some
are mandatory, and conflict with the 2.1 statement that everything is
optional?  In general, there are a lot of different structures defined
here, if some are required, others not, a shorthand way of flagging them
one way or the other might be super-helpful to implementers

10.1 This is a really substantial and complicated registry.  I’d like to
see some remarks about why a registry is called for in this case.  Sorry if
it was there and I missed it.

Speaking as a person who’s been skeptical of JSON schema efforts, it pains
me to say this, but the information about large-scale message structure is
scattered through this document in a diffuse way and it’d make me nervous
as an implementer whether or not I was getting it right.  I think it might
be helpful to have a “large-scale message structure” section that quickly
runs through the allowable top-level shapes of messages, and exactly what
can be nested inside what.

Nits

1.1 Section numbers might be nice on the 7159 references, e.g. for Object

1.2 first para: “… is conveyed in four sections”. Followed by a 5-member
list

1.2 “The following object classes are served by…”  What does it mean for an
“object class” to be “served”. Do you mean “returned in response to a
request?

2.1 “…SHOULD ignore unrecognized JSON attributes in responses”  What’s a
JSON attribute?  Do you mean unknown members in objects?

2.1 “This allowance does not apply to jCard”.  The word “allowance” puzzles
me.  Do you mean the rule about the underscores?

2.1 “these limitations have been given to aid some client programming
models” uh, “given to aid”. Do you mean “observed to aid” or “shown to aid”
or some such?

3. “used in this document derived from the JSON character string”.  What
does “derived from” mean?  Do you mean to say that all the data types in
this section are encoded as JSON strings?

4.1 “The first data structure…”  First in what sense?  Is it extra
important? Must appear first in the JSON instance? (I assume not, that’s a
very bad practice).

4.9 Object Class Name is actually (as with a few other things here) a
name/value member of an object (if I’m reading correctly); why not say so?

5.1 the example.vcard there’s an array containing ["", "", "", ... which
looked kind of weird to me.  I’m assuming this will make perfect sense to
someone who knows vcards?

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Oct 2014 15:54:49 -0700

Hi Tim,

> considerations.  If I were on the IESG I’d be having heartburn.

Are the things you have in mind here specific to RDAP, or are they general
DNS considerations applicable to most application layer things?  I don't
know that we need to call out general vulnerabilities unless we're
particularly sensitive to them, but new concerns definitely need to be
called out.

-MSK

---

From: Tim Bray <[email-masked]>
Date: Mon, 27 Oct 2014 16:03:39 -0700

I suffer from a lack of expertise in the subject domain, but this payload
is going to be used to guide people to what they think are the domains they
are looking for.  If I were a bad guy I’d think carefully about how I might
mis-use this payload for my own gain.  RFC7159 calls out interop pain
points in JSON, could any of those serve as attack vectors? Or maybe a
callout to the Security Considerations in the appropriate DNS specs might
do the job?

Also it’s possible that, even in these troubled times, my reflexive “WTF
DNS with no security considerations?!?!?!” is overdone.

On Mon, Oct 27, 2014 at 3:54 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> 10.1 The only security consideration in a protocol definition is the
>> basic JSON stuff?  Really?  DNS vulnerabilities can be horribly damaging to
>> the Internet; it’s hard to believe you can just skip over security