Attaching Meaning to Solicitation Class Keywords
draft-malamud-keyword-discovery-05

IANA Comments:
Upon approval of this document the IANA will update the S-NAPTR Application Service Tags registry to include the "no solicit" tag.
Registry found at http://www.iana.org/assignments/s-naptr-parameters

[Ballot comment]
Moved DISCUSS to COMMENTS as requested by Mark Townsley:

The Abstract needs to be rewritten.

There is no Introduction, though Section 1 sorta-kinda looks like one in construction if not heading.

I agree with other DISCUSS points that this document does not *yet* stand on its own, and am concerned that there may security issues with passing around what amount to lightly obfuscated DNS names.

Nits:

>    inserted in a "No-Solicit:" header or in a trace field.  [RFC3865]
>    explicitly placed discovery of the meaning of a solicitation class

s/placed/places

>    keywords as outside of the scope of the basic ESMTP service

s/keywords/keyword

>    If that standard becomes widely deployed, a  mail message might

What standard? I assume RFC3865 (which is not a "Standard" in the strict sense), but since this is the start of a brand new paragraph it is not immediately clear what "that" is referring to.

Also, there are multiple spaces before "mail" on this line.

[Ballot comment]
The Abstract needs to be rewritten.

There is no Introduction, though Section 1 sorta-kinda looks like one in construction if not heading.

I agree with other DISCUSS points that this document does not *yet* stand on its own, and am concerned that there may security issues with passing around what amount to lightly obfuscated DNS names.

Nits:

>    inserted in a "No-Solicit:" header or in a trace field.  [RFC3865]
>    explicitly placed discovery of the meaning of a solicitation class

s/placed/places

>    keywords as outside of the scope of the basic ESMTP service

s/keywords/keyword

>    If that standard becomes widely deployed, a  mail message might

What standard? I assume RFC3865 (which is not a "Standard" in the strict sense), but since this is the start of a brand new paragraph it is not immediately clear what "that" is referring to.

Also, there are multiple spaces before "mail" on this line.

[Ballot comment]
Moving the DISCUSS to COMMENT as per Brian Carpenter's request:

From Spencer Dawkins, Gen-Art reviewer:

Summary: This document is on the right track, but still has a couple of opportunities for improvement.

The reader has to work to dig out the goal here - I THINK the goal is "given an RFC 3865 solicitation class keyword, discover a URI that points to a resource that tells you what the RFC 3865 keyword actually means", but I'm still not sure about this. The document is correctly pointing to RFC 3865 for its context, but it doesn't stand on its own. Given this, the non-normative example is going to have a lot of influence on the reader's understanding.

(Thus pointing out another opportunity to use the proposed ISD mechanism to clump specifications. But I digress.)

The Security Considerations concern raised is really broad. Is it saying more than "DNSSEC would help a lot of things, including this mechanism", or is this mechanism simply subject to a broad class of insecure-DNS-based vulnerabilities? What is really at risk here? Even saying "in the absence of DNSSEC, this mechanism can be exploited to give mail users incorrect guidance on keyword interpretation", or something. Mumble.

  Use of a URI with the "https:" scheme without the use of DNSSEC makes
  an unwarranted illusion of authenticity and the possibility of active
  attacks a serious concern.

[Ballot discuss]
Actually a topic for DISCUSSion...

This document falls into a class of document that uses DNS names (or reverse-order DNS names) as persistent identifiers.  As I have indicated earlier, I am uncertain that this is a reasonable use for a leased (i.e. non-permanently-assigned) string.  When I raised this on an earlier document (of Jonathan Rosenberg's), the response I got was the equivalent of "interesting question, hadn't thought of that".  Some other folks also indicated that we have done this in the past and that it doesn't necessarily require that the domain allocation be permanent.

This document would seem (on a quick reading) to further complicate this situation by assuming that the person who originally allocated the identifier will continue to have the authority to serve domain names in that name space.

Thoughts?

I think I might like to discuss this topic with pertinent experts, but I'm not quite sure where to find them.  The DNS directorate might be good for one part of the problem.  Do we have  a more general name space directorate somewhere?

[Ballot discuss]
Actually a topic for DISCUSSion...

This document falls into a class of document that uses DNS names (or reverse-order DNS names) as persistent identifiers.  As I have indicated earlier, I am uncertain that this is a reasonable use for a leased (i.e. non-permanently-assigned) string.  When I raised this on any earlier document (of Jonathan Rosenberg's, the response I got was the equivalent of "interesting question, hadn't thought of that".  Some other folks also indicated that we have done this in the past and that it doesn't necessarily require that the domain allocation be permanent.

This document would seem (on a quick reading) to further complicate this situation by assuming that the person who originally allocated the idenfier will continue to have the authority to serve domain names in that name space.

Thoughts?

I think I might like to discuss this topic with pertinent experts, but I'm not quite sure where to find them.  The DNS directorate might be good for one part of the problem.  Do we have  a more general name space directorate somewhere?

[Ballot discuss]
Actually a topic for DISCUSSion...

This document falls into a class of document that uses DNS names (or reverse-order DNS names) as persistent identifiers.  As I have indicated earlier, I am uncertain that this is a reasonable use for a leased (i.e. non-permanently-assigned) string.  When I raised this on any earlier document (of Jonathan Rosenberg's, the response I got was the equivalent of "interesting question, hadn't thought of that".  Some other folks also indicated that we have done this in the past and that it doesn't necessarily require that the domain allocation be permanent.

This document would seem (on a quick reading) to further complicate this situation by assuming that the person who originally allocated the idenfier will continue to have the authority to serve domain names in that name space.

Thoughts?

I think I might like to discuss this topic with pertinent experts, but I'm not quite sure where to find them.  The DNS directorate might be good for one part of the problem.  Do we have  a more general name space directorate somewhere?

[Ballot discuss]
The Abstract needs to be rewritten.

There is no Introduction, though Section 1 sorta-kinda looks like one in construction if not heading.

I agree with other DISCUSS points that this document does not *yet* stand on its own, and am concerned that there may security issues with passing around what amount to lightly obfuscated DNS names.

Nits:

>    inserted in a "No-Solicit:" header or in a trace field.  [RFC3865]
>    explicitly placed discovery of the meaning of a solicitation class

s/placed/places

>    keywords as outside of the scope of the basic ESMTP service

s/keywords/keyword

>    If that standard becomes widely deployed, a  mail message might

What standard? I assume RFC3865 (which is not a "Standard" in the strict sense), but since this is the start of a brand new paragraph it is not immediately clear what "that" is referring to.

Also, there are multiple spaces before "mail" on this line.

[Ballot discuss]
The abstract is insufficient as it is not very useful in determining
what the use case is for this document.

In addition, I received the following comments from the Ops directorate.
I agree with the comments, and more specificly, I would like to ask the DSNOP
community for a review before approving this document.

Comments from the OPS directorate by Pekka Savola (Mar 30 17:47:13 PST 2005):

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).

....

Also noting similar but at a higher level for
draft-malamud-subject-line-03.txt.

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 -- then 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
flushed out in Security Considerations.

[Ballot discuss]
The security considerations say:
  >
  > Use of a URI with the "https:" scheme without the use of DNSSEC makes
  > an unwarranted illusion of authenticity and the possibility of active
  > attacks a serious concern.
  >
  I completely agree, but I think that the thought process needs to be
  captured here, not just the conclusion.  Some questions that need to
  be answered in the discussion include:

  - What are the consequences of not using DNSSEC?

  - What are the consequences of not using https?

  - When https are used, what identity ought to be represented in
    the SSL/TLS certificate?

  - When both DNSSEC and https are used, what things need to be aligned
    so that the client can tell that the two different digital signature
    validation contexts are being administered by the same domain owner?

[Ballot discuss]
These are only just DISCUSS points and I will clear this if the shepherd will pick them up.

From Spencer Dawkins, Gen-Art reviewer:

Summary: This document is on the right track, but still has a couple of opportunities for improvement.

The reader has to work to dig out the goal here - I THINK the goal is "given an RFC 3865 solicitation class keyword, discover a URI that points to a resource that tells you what the RFC 3865 keyword actually means", but I'm still not sure about this. The document is correctly pointing to RFC 3865 for its context, but it doesn't stand on its own. Given this, the non-normative example is going to have a lot of influence on the reader's understanding.

(Thus pointing out another opportunity to use the proposed ISD mechanism to clump specifications. But I digress.)

The Security Considerations concern raised is really broad. Is it saying more than "DNSSEC would help a lot of things, including this mechanism", or is this mechanism simply subject to a broad class of insecure-DNS-based vulnerabilities? What is really at risk here? Even saying "in the absence of DNSSEC, this mechanism can be exploited to give mail users incorrect guidance on keyword interpretation", or something. Mumble.

  Use of a URI with the "https:" scheme without the use of DNSSEC makes
  an unwarranted illusion of authenticity and the possibility of active
  attacks a serious concern.

Comments from Michael Mealling, expert reviewer:
"The use of this DDDS application is in line with the use and purpose of the DDDS, uses the algorithm correctly, and does not introduce any uses or side effects that would harm the DNS or the Internet in any perceptible way. This expert is not qualified to review that actual efficacy of the entire system however."

Appendix A should be revised.  It currently reads "This draft is being submitted to the RFC Editor as an individual submission with an intended publication as a Proposed Standard".  It didn't go to the RFC Editor, it came to the Application ADs.

I will ask Michael Mealling to do an expert review check on the document.