Revision differences

Document history

Received changes through RFC Editor sync (changed abstract to 'This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which ...

Received changes through RFC Editor sync (changed abstract to 'This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.

This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]')

2015-10-14

05

(System)

Notify list changed from carl@media.org to (None)

2012-08-22

05

(System)

post-migration administrative database adjustment to the No Objection position for Margaret Wasserman

2012-08-22

05

(System)

post-migration administrative database adjustment to the No Objection position for Brian Carpenter

2012-08-22

05

(System)

post-migration administrative database adjustment to the No Objection position for Mark Townsley

2012-08-22

05

(System)

post-migration administrative database adjustment to the No Objection position for David Kessens

2012-08-22

05

(System)

post-migration administrative database adjustment to the No Objection position for Russ Housley

2005-05-31

05

Amy Vezza

State Changes to RFC Published from RFC Ed Queue by Amy Vezza

2005-05-31

05

Amy Vezza

[Note]: 'RFC 4095' added by Amy Vezza

2005-05-27

05

(System)

RFC published

2005-05-16

05

Amy Vezza

State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza

2005-05-10

05

Amy Vezza

IESG state changed to Approved-announcement sent

2005-05-10

05

Amy Vezza

IESG has approved the document

2005-05-10

05

Amy Vezza

Closed "Approve" ballot

2005-05-10

05

Scott Hollenbeck

State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Scott Hollenbeck

2005-05-10

05

Scott Hollenbeck

Removed from agenda for telechat - 2005-05-12 by Scott Hollenbeck

2005-05-10

05

Scott Hollenbeck

Note field has been cleared by Scott Hollenbeck

2005-05-09

05

David Kessens

[Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens

2005-04-30

05

Scott Hollenbeck

Placed on agenda for telechat - 2005-05-12 by Scott Hollenbeck

2005-04-30

05

Scott Hollenbeck

[Note]: 'Returning to clear the last discuss.' added by Scott Hollenbeck

[Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley

2005-04-01

05

(System)

Sub state has been changed to AD Follow up from New Id Needed

2005-04-01

04

(System)

New version available: draft-malamud-keyword-discovery-04.txt

2005-04-01

05

Amy Vezza

[Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Amy Vezza

2005-04-01

05

Amy Vezza

[Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Amy Vezza

2005-04-01

05

Amy Vezza

[Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Amy Vezza

2005-04-01

05

Amy Vezza

[Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Amy Vezza

2005-04-01

05

Mark Townsley

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

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

2005-04-01

05

Mark Townsley

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

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

2005-03-31

05

Amy Vezza

State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza

2005-03-31

05

Amy Vezza

[Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Amy Vezza

2005-03-31

05

Brian Carpenter

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

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

2005-03-31

05

Margaret Cullen

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

[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?

2005-03-31

05

Alex Zinin

[Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin

2005-03-31

05

Margaret Cullen

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

[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?

2005-03-31

05

Margaret Cullen

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

[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?

2005-03-31

05

Margaret Cullen

[Ballot Position Update] New position, Discuss, has been recorded for Margaret Wasserman by Margaret Wasserman

2005-03-31

05

Mark Townsley

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

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

2005-03-31

05

Mark Townsley

[Ballot Position Update] New position, Discuss, has been recorded for Mark Townsley by Mark Townsley

2005-03-31

05

Bill Fenner

[Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner

2005-03-30

05

David Kessens

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

In addition, I ...

[Ballot discuss]The abstract is insufficient as it is not very useful in determiningwhat 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.

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

....

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

The document seems to assume that the users are able to insertproperly 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'sresources (assuming specifying something like net.example.adv wouldresult in everyone going and taking a look at "adv" policy atexample.net -- then flooding example.net).

A maliscious advertiser could also insert improperly formattedkeywords, or insert 100 such keywords which will time out, consumingeven 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 todo that properly is an open issue.

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

2005-03-30

05

David Kessens

[Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens

2005-03-30

05

Russ Housley

[Ballot discuss]The security considerations say: > > Use of a URI with the "https:" scheme without the use of DNSSEC makes ...

[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?

2005-03-30

05

Russ Housley

[Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley

2005-03-28

05

Brian Carpenter

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

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

2005-03-28

05

Brian Carpenter

[Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter

2005-03-24

05

Scott Hollenbeck

Placed on agenda for telechat - 2005-03-31 by Scott Hollenbeck

2005-03-24

05

Scott Hollenbeck

State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Scott Hollenbeck

2005-03-24

05

Scott Hollenbeck

[Ballot Position Update] New position, Yes, has been recorded for Scott Hollenbeck

2005-03-24

05

Scott Hollenbeck

Ballot has been issued by Scott Hollenbeck

2005-03-24

05

Scott Hollenbeck

Created "Approve" ballot

2005-03-22

05

(System)

State has been changed to Waiting for AD Go-Ahead from In Last Call by system

2005-02-22

05

Amy Vezza

Last call sent

2005-02-22

05

Amy Vezza

State Changes to In Last Call from Last Call Requested by Amy Vezza

2005-02-21

05

Scott Hollenbeck

Last Call was requested by Scott Hollenbeck

2005-02-21

05

Scott Hollenbeck

State Changes to Last Call Requested from AD Evaluation::AD Followup by Scott Hollenbeck

2005-02-21

05

(System)

Ballot writeup text was added

2005-02-21

05

(System)

Last call text was added

2005-02-21

05

(System)

Ballot approval text was added

2005-02-21

03

(System)

New version available: draft-malamud-keyword-discovery-03.txt

2005-02-21

05

(System)

Sub state has been changed to AD Follow up from New Id Needed

2005-02-21

02

(System)

New version available: draft-malamud-keyword-discovery-02.txt

2005-02-18

05

Scott Hollenbeck

State Changes to AD Evaluation::Revised ID Needed from Expert Review by Scott Hollenbeck

2005-02-18

05

Scott Hollenbeck

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

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

2005-02-18

05

Scott Hollenbeck

State Changes to Expert Review from AD Evaluation by Scott Hollenbeck

2005-02-18

05

Scott Hollenbeck

Appendix A should be revised. It currently reads "This draft is being submitted to the RFC Editor as an individual submission with an intended ...

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.

2005-02-18

05

Scott Hollenbeck

State Changes to AD Evaluation from Publication Requested by Scott Hollenbeck