Subject: Re: [dnsop] please review draft-malamud-keyword-discovery-03.txt

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Apr 2005 09:46:39 +0300 (EEST)

On Thu, 31 Mar 2005, David Meyer wrote:
>> 	Our AD (and others) have asked if we could review
>> 	draft-malamud-keyword-discovery-03.txt. If you have the
>> 	time, a critical review would be much appreciated.
>
> 	Brief update. The IESG would like our feedback on this
> 	document within a 2 weeks, if possible (say by around 15
> 	Apr 2005).

In trying to get the folks to take a peek and to get the comments 
started, here's my opinion (already expressed in another forum):

This seems like an interesting approach, but I do not think the 
implications of this have been sufficiently reviewed, especially by 
the DNSOPs community.  Maybe this would also warrant a bit more 
discussion in the "anti-spam" communitities (whichever those are).

....

The document seems to assume that the users are able to insert 
properly formatted and correct solicitation keywords in the message, 
which can be sanely parsed by a computer.

Effectively, this allows anyone to perform a DoS on someone else's 
resources (assuming specifying something like net.example.adv would 
result in everyone going and taking a look at "adv" policy at 
example.net -- thus flooding example.net).

A maliscious advertiser could also insert improperly formatted 
keywords, or insert 100 such keywords which will time out, consuming 
even more processing than receiving the message would have done.

Improperly formatted entries like 'No-Solicit: dont-spam-me-plaase' 
also cause the root servers to be bombarded with bogus DNS queries. 
Maybe the parser needs to discard some more bogus entries, but how to 
do that properly is an open issue.

This should probably be discussed in the draft, and security issues 
fleshed out in Security Considerations.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Peter Koch <[email-masked]>
Date: Mon, 18 Apr 2005 14:56:34 +0200

> example.net -- thus flooding example.net).

the document [-04] does not explicitly say that processing of those tags would
be automated. Instead my reading is that these tags, or the documents they lead
to, are for human consumption. So while there's still a DNS DoS potential
(or even worse, thinking of the current cache poisoning hype), it's probably
less pressing. Anyway these issues and how and when the names are resolved
should be explicitly discussed.

Here are some additional remarks:

o Two forms of solicitation tags are used interchangeably in the draft:
  net.example:ADV and net.example.adv. While both are translated to the same
  domain name, which is the correct form?

o Is the colon mandatory?

o The script suggests that a name example.com:FOO.Bar is translated into
  Bar.FOO.example.com -- is that the intent?

o The draft does not mention various syntax restrictions for the tags resulting
  from the use of the DNS: label length, overall tag length, unavailability
  of ".." (likewise "::", ":.", ".:"). Also, neither RFC 3865 nor this
  draft mention case insensitivity.

o While the presence of the "_" should not lead to problems during NAPTR
  resolution, it may confuse operators (dto absence of restrictions for "-").

o The draft mentions the "registrant" where the better term would be zone
  maintainer (or owner), since a registrant only appears at the highest
  "registration" level. One could argue that the 3rd level domain is
  "registered" at the 2nd level, but that's confusing the term. Unfortunately
  this already happened in RFC 3865.

o solicitation class tags have a very restricted character set, especially
  they don't support non ASCII characters. In what form would IDNs be
  handled? Would "xn--" encoding also apply to the past-colon part?

o Are the solicitaion class keywords expected to be related to the sender's
  domain name, the recipient's or a third party's? Do "users" of this scheme
  thus have to deal with NAPTR RRs?

o The wildcard discussion

	Wildcards are appropriate for this application, allowing multiple
	solicitation class keywords that share a common prefix to all point
	to the same URI

  seems to encourage the use of wildcards to solve the provisioning issue.
  A big caveat text might be appropriate then.

-Peter
.

---

From: Carl Malamud <[email-masked]>
Date: Mon, 18 Apr 2005 07:46:56 -0700 (PDT)

>   domain name, which is the correct form?

Both are valid.

> o Is the colon mandatory?

No, and for the ddds app, one does s/:/./g as part of the first well-known
rule.

>   Bar.FOO.example.com -- is that the intent?

Yes.

>   draft mention case insensitivity.

3865 does, I believe, restrict each part of a label to be valid, and does
deal with overall tag length and stuff.

>   this already happened in RFC 3865.

Hmmm ... suggestions at this point on what I should do?  Registrant came from
several folks because it implies "person with admin control and people whom
have been delegated that capability by the person with admin control".

>   handled? Would "xn--" encoding also apply to the past-colon part?

IDN sits in valid domain names, so each part of a label could in fact be
encoded in IDN.  The colon is syntactically equivalent to a period, so the
rules apply to post-colon parts.

>   thus have to deal with NAPTR RRs?

Nobody has to deal with NAPTR RR's, but this does give the UI designer the ability
to do lookups.  However, a solicitation class keyword might come from the
sender, it might come from somebody else.  For example, a policy maker might
require the use of gov.example.adv, the sender might do com.example.iwanttoselltoyou,
a voluntary industry group might allow the use of org.example.betterbusinessburea,
and the very sophisticated marketer might even include a special label that
the recipient has invented to get past filters.  So, the answer is all of the
above.

>   A big caveat text might be appropriate then.

Doesn't really encourage them so much as say (along with other DDDS apps)
that they have a potential role and you should look to current best practices.
At least, that's what I meant.  :)  (DDDS requires that I state if they
are allowed or not, so I did. )

Let me know if I've answered your questions ... I'm hoping not to revise since
we're so far along, but if that's what it takes, I'm happy to do so.  With a
couple small exceptions, I read your queries all as request for clarification,
not revision, but I may have been overly optimistic.  :)

Regards,

Carl
.

---

From: Peter Koch <[email-masked]>
Date: Tue, 19 Apr 2005 19:55:44 +0200

> >   domain name, which is the correct form?

So, they seem to be equal, but what's the point in having the ':' then?
RFC 3865 says: "The initial set of solicitation class keywords all begin with
a domain name with the labels reversed, followed by a colon." Isn't that
normative?

> No, and for the ddds app, one does s/:/./g as part of the first well-known

Sure, but if there's no semantic difference a comment to that regard could
clarify this.

> deal with overall tag length and stuff.

It says that the tag (or list of tags) may not exceed 1000 characters in length,
but does not constrain the length to 253 characters or the label length to
63. Also it allows "an arbitrary set of characters drawn from the following
construct", where you can't translate example.com:Foo::Bar into a valid
domain name.

> have been delegated that capability by the person with admin control".

Zone administrator is a more neutral term because that applies at every level
whereas "registrant" is ICANNish vocabulary for someone having registered
a domain name with a "registry". "dissident.example.com" may be administered
by an entity applying different policies than the entity responsible for
"example.com".

> rules apply to post-colon parts.

But then I couldn't have "org.äntispäm:SPÄM" in the header (not even properly
MIME-Header encoded), but would have to write "org.xn--ntispm-9taf:xn--spm-rla".
For the part left of the colon an application or library might help, but
identifying the part after the ':' as a domain label is tough.

> are allowed or not, so I did. )

NAPTR suffers from the subtyping problem, even more if applied at a zone apex
or with wildcards - that's why I'd prefer them being explicitly discouraged.
And wildcards are often abused to solve the provisining problem, i.e. to
save the administrator the work to enter several predictable RRs into the zone.

> couple small exceptions, I read your queries all as request for clarification

Well yes, most :-) Thanks for your quick response.

-Peter

.

---

From: Carl Malamud <[email-masked]>
Date: Tue, 19 Apr 2005 11:07:38 -0700 (PDT)

[ Charset ISO-8859-1 unsupported, converting... ]
> a domain name with the labels reversed, followed by a colon." Isn't that

Um, yes, that would be normative.  :)  That's an artifact of the previous
drafting process for 3865 (we thought we were using an iana registry and
then moved to the reversed domain name issue.  Let me address this
specifically.

> Sure, but if there's no semantic difference a comment to that regard could

Will do.

> construct", where you can't translate example.com:Foo::Bar into a valid

Hmmm ... let me figure out how to deal with it.  A valid point.

> by an entity applying different policies than the entity responsible for

Not a problem ... I can clarify this.

> But then I couldn't have "org.?ntisp?m:SP?M" in the header (not even properly

OK ... I do see the issue here.  Let me consult with a couple of people who
are more idn literate than I am and propose an answer.  I think the answer is
s/:/./ then apply IDN, but I hear what you're saying on the ambiguity and I
think this may require a sentence explaining what to do if you're going to
use the naptr-based scheme in conjunction with 3865.  Again, I think there
is a clean solution, but let me make sure it works.

> save the administrator the work to enter several predictable RRs into the zone.

I can add a note explaining that issue, but I'd like to come down in favor
of wild cards.  That said, I think the issue needs to be clearly stated.

Regards,

Carl
.