Subject: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Wed, 29 Oct 2014 11:47:49 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-weirds-rdap-query-16: Discuss

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-query/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Point 1:

In section 3.1.1, it's not clear which of three alternative things you
may have been specifying: (1) the ASCII representation of the IP address
is intended to be converted to binary before use, (2) the ASCII
representation is intended to be used directly, or (3) whether the IP
address is converted to binary prior to use is an implementation choice. 
 If (1) is what's intended, you should say so explicitly.   If either (2)
or (3) is intended, then the representation that's used needs to be in
some canonical form, and the text as written does not ensure that it will
be.

So to address this discuss, you should either update the text to say that
(1) is what's intended, and it won't work otherwise, or you need to
require, not suggest, a canonical representation.   If you go with the
second option, your reference to RFC 5952 isn't adequate: you need to
specifically reference section 4, and specifically exclude section 5.   I
have no preference as to how you resolve this.

Point 2:

In 3.1.3, the instructions as given don't really guide implementations
toward interoperability.   Why not just say that servers SHOULD either
convert a-labels to u-labels, or u-labels to a-labels, and be done with
it?   It's not like it's a difficult conversion, and they have to do the
conversion to do the comparison, unless for some reason they store both
A- and U-labels as keys in their database, which seems really unlikely.  
The recommendations are written are so vague that I would expect
interoperability to only be likely in the case of queries that contain no
IDN labels.   I wouldn't mind this in an Informational document, but it's
pretty sketchy in a standards-track document.

It's particularly weird that in one place you say "An RDAP server that
receives a query string with a mixture of A-labels and U-labels MAY
convert all the U-labels to A-labels, perform IDNA processing, and
proceed with exact-match lookup" and then in the next paragraph you say
"The server MAY perform the match using either the A-label or U-label
form.  Using one consistent form for matching every label is likely to be
more reliable."

I'm not sure how to resolve this.   I think there's some underlying
decision the working group has made that led to this language, but the
lack of consistency I mention above leads me to wonder if either that
decision wasn't very clear, or the document failed to reflect it.  
Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to
how IDNs are represented.

In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches
are for spammers to identify related domains, and for eavesdroppers to do
the same.   What's the motivation for including these capabilities?   At
a minimum, the privacy considerations for this search ought to be
discussed in a privacy considerations section or in the security
considerations section.

Point 3:

In 4.1, you don't actually specify the syntax for partial string matches.
  I think I can intuit what you mean, but you should be explicit, and you
shouldn't suggest using POSIX regex searches unless that's what you
really mean; if that's what you really mean, then you need to do a lot
more work than you've done.   I _think_ what you intend is to simply say
that if one or more asterisks appear in a label, then when the search is
done, any label that contains the non-asterisk characters in sequence
plus zero or more characters in sequence in place of each asterisk would
match.   But you don't actually say that, so I'm not sure what you
actually intended.   The text could be read to mean that any arbitrary
search mechanism is allowed, but if that's the case then you need to go
into a lot more detail about the caveats, such as the '.' character in
posix regexps and the start and end markers.

The text on partial matches for unicode also seems unnecessarily
complicated, and likely not implementable without massive knowledge of
all the various unicode character sets, which I would not expect an
implementation to bother with.   It seems relatively harmless to allow
searches on combining characters, particularly since it would be a lot of
work to prevent it.   For example, a search for *ཀ་ would not find all
instances of a syllable that starts with the sound "ka" because ka can be
either a head letter or subjoined, but a user might search first using
the head letter and then the subjoined letter if (as is not unlikely) he
or she were unsure of the correct spelling.   It would be a shame if such
a search were rendered impossible by an overly-thorough implementation of
the current text.

As I say, I don't really know what was intended here, so I can't make a
definite suggestion as to what the right thing to do is to fix this; I
think we just need to discuss it, hence the discuss point.

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

Point A:

In 3.1.2:

   For example, the following URL would be used to find information
   describing autonomous system number 12 (a number within a range of
   registered blocks):

   http://example.com/rdap/autnum/12

   The following URL would be used to find information describing 4-byte
   autonomous system number 65538:

   http://example.com/rdap/autnum/65538

The examples don't really seem to illustrate what is said in the text.  
The syntax for both examples is the same, and we don't see any return
results.   So to say that one example is an example of a number within a
range of registered blocks, while the other is a 4-byte number, doesn't
make sense because the query formats are identical.   The preceding text
is clear, if I understand it correctly: a number in the path element
following 'autnum' is an autonomous system number, which references a
block of one or more numbers.   If there are additional semantics, e.g.,
byte size boundaries for AS numbers, that are also encoded in the query,
those should be described explicitly.   But IMHO that doesn't make sense:
in _this_ context, these are just decimal numbers of arbitrary precision,
and how many bytes they are, or whether any particular number references
a block or just a single number, is not something that should be
mentioned in the examples.

Point B:

Section 6 appears to be confusing presentation and representation.   A
client might well present a UI that shows U-labels, but use A-labels on
the back end.   The text as written here really doesn't make sense.  
What are you trying to say?   I think that you shouldn't confuse what's
presented to the user with what's sent on the wire.   Possibly this is
related to the confusion over A-labels and U-labels that I called out in
Point 2 of the discuss.

---

From: Andy Newton <[email-masked]>
Date: Wed, 29 Oct 2014 22:45:30 +0000

> have no preference as to how you resolve this.

It is option 3. However, the implementer wishes to construct a database is up to the implementer. They need to be able to parse IPv6 addresses and use them to construct whatever key their database uses, be it textual or binary. Having implemented both forms, you cannot simply take the textual representation and use that as a key.

All that being said, I don’t understand the suggested fix. Section 5 of RFC 5952 is about IPv4 embedded addresses in IPv6 addresses. But they are different addresses. There is no collision so the need for canonicalization isn’t obvious. Cutting embedded-IPv4 addresses does make implementation easier, and I don’t think anybody would actually care if they were explicitly forbidden.

> discussed in a privacy considerations section or in the security

Nameserver searches return nameserver objects. I don’t know how useful that would be a to a spammer, but to a nameserver operator trying to determine which registrations are pointing to their nameserver, that seems useful.

Those examples seem far away from that reference to ASPLAIN and RFC 5396. The point is: don’t do ASDOT… which is an issue for 4-byte as numbers. We should probably actually say that, and split apart the first paragraph to put the examples closer to it.

-andy

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 18:59:46 -0400

> It is option 3. However, the implementer wishes to construct a database is up to the implementer. They need to be able to parse IPv6 addresses and use them to construct whatever key their database…

You seem to be saying it's option 1, then, not option 3.

> All that being said, I don’t understand the suggested fix. Section 5 of RFC 5952 is about IPv4 embedded addresses in IPv6 addresses. But they are different addresses. There is no collision so the n…

It should be the case that there isn't more than one way to represent the IP address.   Or else it should be the case that the server is required to accept the IP address no whether it is canonicalized or not.  You have to tell the client what to expect.   If it's okay for the client to send any old syntactically valid IP address, that's fine, but the document doesn't currently say that, and so a server implementor might _assume_ that you mean that only addresses canonicalized according to section 4 of RFC 5952 are permitted.   The point of normative language is to make sure that we don't rely on the implementor to make the same assumptions we made.

> Nameserver searches return nameserver objects. I don’t know how useful that would be a to a spammer, but to a nameserver operator trying to determine which registrations are pointing to their names…

Wouldn't they already know, since they configured the name server?

---

From: Andy Newton <[email-masked]>
Date: Wed, 29 Oct 2014 23:24:28 +0000

> It should be the case that there isn't more than one way to represent the IP address.   Or else it should be the case that the server is required to accept the IP address no whether it is canonical…

Now I understand. Thanks.

> Wouldn't they already know, since they configured the name server?

Not necessarily. How a nameserver object is mapped in a registry is not a detail needed to configure a nameserver to accept queries for a domain.

-andy

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 19:49:44 -0400

> Not necessarily. How a nameserver object is mapped in a registry is not a detail needed to configure a nameserver to accept queries for a domain.

OK, that use case does make some sense.  My concern is that it will be used for data mining by people other than owners of nameservers.   I don't think there's much that can be done to mitigate this, though, so I'll take it out of the DISCUSS.   It wouldn't hurt to mention it specifically in the security considerations section, but I'll leave that up to you.

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Oct 2014 16:53:38 -0700

On just point 2:

On 10/29/14 11:47 AM, Ted Lemon wrote:

> it?

See the discussion in section 6.1, referred to in 3.1.3. Converting to 
u-labels or a-labels can change the search semantics because of 
case-mapping. Remember, the server is trying to do its best in the face 
of clients that might be handing it some pretty dicey stuff. A client 
that does the right thing and only queries all-a-label or all-u-label 
strings is going to get consistent results, because it is taking 
responsibility to do the appropriate mappings. But if the client is 
blindly handing over labels it got from somewhere else (which is why you 
would get mixed stuff), the server is going to do what it can to get 
things right (or decide that it doesn't want to try). So the most 
interoperable thing is to say, "Clients: Query reasonable things. 
Servers: You can choose to be helpful or not on unreasonable things." At 
least that's my understanding of the consensus of the WG and the IDN 
experts consulted; the IDN experts on the list can pipe up if I've 
gotten this wrong.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 20:09:50 -0400

On Oct 29, 2014, at 7:53 PM, Pete Resnick <[email-masked]> wrote:
> A client that does the right thing and only queries all-a-label or all-u-label strings is going to get consistent results, because it is taking responsibility to do the appropriate mappings. But if the client is blindly handing over labels it got from somewhere else (which is why you would get mixed stuff),

Why would the client do that?   Why not specify what the right thing is for the client to do as a SHOULD, and _then_ explain what might break if it doesn't, rather than just sort of talking about it and hoping for the best?

Also, U-labels are case-sensitive.   So the semantic difference you're describing doesn't actually exist.   A-labels are just encoded U-labels.   So if you take an A-label and turn it into a U-label, you can do a comparison between it and another U-label without case folding, and indeed you aren't _allowed_ to do case folding.   And similarly, if you take a U-label and encode it as an A-label, then you can just compare it to other A-labels, because A-label comparisons are case-insensitive with respect to the A-label representation: case-folding does not change the meaning of an A-label.   This is explained in RFC 5891 section 3 bullet point 2.

(BTW, what I just explained in the above paragraph gives me a headache and tells me we should _never_ use IDN for any writing system that has case, because it will be insanely easy to spoof.   But you probably already knew that.)

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Oct 2014 17:32:34 -0700

On 10/29/14 5:09 PM, Ted Lemon wrote:
> On Oct 29, 2014, at 7:53 PM, Pete Resnick<[email-masked]>  wrote:
>    
> Why would the client do that?

Because clients get their input from all sorts of weird places, and some 
not-so-smart clients do not have the machinery to do the right thing. 
They SHOULD, but they don't.

> Why not specify what the right thing is for the client to do as a SHOULD, and _then_ explain what might break if it doesn't, rather than just sort of talking about it and hoping for the best?
>    

But that's exactly what the second full paragraph of 3.1.3 says now: 
SHOULD be either U-Labels or A-Labels, might break if not (see section 
6.1), here are reasons you might see brokenness, and servers can do what 
they will to make things right.

> Also, U-labels are case-sensitive.   So the semantic difference you're describing doesn't actually exist.

If servers could count on only getting real U-labels, of course. And if 
servers could simply reject crappy input out of hand, life would be much 
simpler. But AFAIU this is a case in which some servers (which serve 
particular constituencies) have to be a bit liberal in what they accept. 
So I think we have to give some information in the document about what 
to do when you get "interesting" input.

> (BTW, what I just explained in the above paragraph gives me a headache and tells me we should _never_ use IDN for any writing system that has case, because it will be insanely easy to spoof.   But…

:-)

pr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 21:17:15 -0400

On Oct 29, 2014, at 8:32 PM, Pete Resnick <[email-masked]> wrote:

> But that's exactly what the second full paragraph of 3.1.3 says now: SHOULD be either U-Labels or A-Labels, might break if not (see section 6.1), here are reasons you might see brokenness, and servers can do what they will to make things right.

Right, fair enough.   But what's bothering me is the text that follows that.   Why isn't it a SHOULD that the server should convert U-labels to A-labels?

> If servers could count on only getting real U-labels, of course. And if servers could simply reject crappy input out of hand, life would be much simpler. But AFAIU this is a case in which some servers (which serve particular constituencies) have to be a bit liberal in what they accept. So I think we have to give some information in the document about what to do when you get "interesting" input.

What's a "real U-label?"   If it's unicode, it's a U-label, or else it's garbage.   There is no third alternative.   If it's garbage, just reject it.   When would garbage be something that it would make sense to attempt to use, rather than rejecting?   I think never.