Subject: [ietf-dkim] domain (reputation) semantics: selectors vs. sub-domains

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2006 12:08:00 -0700

Folks,

I've heard a number of different groups say that they plan to make semantic
distinction based on selector.  For example, they intend to send transaction
mail under one selector and marketing mail under another.  Their intent is to
have reputation services distinguish between one domain+selector and another.

I believe this defeats the purpose of the selector and would like to get some
working group discussion and consensus about this.

My understanding of the purpose of the selector mechanism is that it is for
enabling multiple keys under the same domain name, where the domain name is the
basic unit of semantic reference.  Hence, selectors are an administrative
convenience, not a mechanism for public (semantic) distinction.  One example of
intended use is to make the transition to a new key.  As soon as selectors are
part of the reputation semantics, this capability for transition is defeated.

As I understand the DKIM design, the way to make semantic distinctions is with
sub-domains.  Note that these are in the d= parameter of domainkeys-signature
field, rather than in the rfc2822.From field.  So, d=transac.example.com should
get a different reputation from d=market.example.com.  The fact that DKIM has
the domain name be decoupled from any other RFC 2822 header field that uses
domain names makes this model extremely convenient.

Comments?

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Wed, 26 Jul 2006 15:24:05 -0400

My understanding as well that subdomains should be a separator, not the
selector function
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, July 26, 2006 3:08 PM
To: ietf-dkim
Subject: [ietf-dkim] domain (reputation) semantics: selectors vs.
sub-domains

Folks,

I've heard a number of different groups say that they plan to make
semantic
distinction based on selector.  For example, they intend to send
transaction
mail under one selector and marketing mail under another.  Their intent
is to
have reputation services distinguish between one domain+selector and
another.

I believe this defeats the purpose of the selector and would like to get
some
working group discussion and consensus about this.

My understanding of the purpose of the selector mechanism is that it is
for
enabling multiple keys under the same domain name, where the domain name
is the
basic unit of semantic reference.  Hence, selectors are an
administrative
convenience, not a mechanism for public (semantic) distinction.  One
example of
intended use is to make the transition to a new key.  As soon as
selectors are
part of the reputation semantics, this capability for transition is
defeated.

As I understand the DKIM design, the way to make semantic distinctions
is with
sub-domains.  Note that these are in the d= parameter of
domainkeys-signature
field, rather than in the rfc2822.From field.  So, d=transac.example.com
should
get a different reputation from d=market.example.com.  The fact that
DKIM has
the domain name be decoupled from any other RFC 2822 header field that
uses
domain names makes this model extremely convenient.

Comments?

d/
-- 

  Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Wed, 26 Jul 2006 19:46:02 +0000

> working group discussion and consensus about this.

Someone said that protocol abuse, defined success. Was that you Dave?

In any event, the question is, what can be done about it? If we can't
stop it in the protocol, at best we can write unread admonishments.

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jul 2006 13:49:05 -0700

>stop it in the protocol, at best we can write unread admonishments.
Right, and one wonders how one could prevent a learning system from
learning those idiosyncracies -- be they by design or not.

       Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 26 Jul 2006 14:07:23 -0700

> stop it in the protocol, at best we can write unread admonishments.

I don't think anyone is /actually/ doing selector-based reputation yet, 
though some of us have been thinking and even talking about it.

The need is for a sender (who has been declared trustworthy by the 
receiver via some entirely unrelated mechanism) to define different 
classes of mail within the same user-facing domain.  Doug tried to 
answer this need with his r= proposal, but it made too many assumptions 
about what those classes of mail would be and how they'd be treated.  If 
subdomains can fill the need without adding any new complexity -- and it 
sounds like they can -- then that's easy enough.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Jul 2006 16:52:43 -0700

On Jul 26, 2006, at 2:07 PM, J.D. Falk wrote:

> I don't think anyone is /actually/ doing selector-based reputation  
> yet, though some of us have been thinking and even talking about it.

There could be a convention where only the right-most Selector is  
considered when identifying the source.  This would allow the left  
most labels within the Selector to be used for key management.  Just  
as there was difficulty reaching consensus for more than three r=  
values, Selector label names may be even harder, especially as this  
also affects key handling.

> answer this need with his r= proposal, but it made too many  
> assumptions about what those classes of mail would be and how  
> they'd be treated.

The r= permits partitioning sources using a common key when desired.   
The r= proposal has been simplified from the first suggestion in  
response to feedback, see:

http://www.ietf.org/internet-drafts/draft-otis-dkim-reliance- 
level-00.txt

Much as with the Selector, the r= parameter couples with the key.   
The basic concept this designation provides improved message  
annotation in a fashion similar to that of Priority or Importance  
headers.

   r=1 (Assured)
   r=0 (Normal or default)
   r=-1 (Not Assured)

Perhaps a company wanting to retain a good reputation for their  
Assured or high reliance assertions, limits which sources can obtain  
the r=1 value.  All other mail may normally receive nothing (r=0).   
In cases where perhaps the source of the message is poorly vetted,  
r=-1 could be used.  Each of these separate categories can achieve a  
separate reputation, and should also help the recipient when this is  
included as part of the message annotation.

> If subdomains can fill the need without adding any new complexity  
> -- and it sounds like they can -- then that's easy enough.

Sub-domains will likely introduce additional visual confusion.   
People may not recognize accounts.example.com as being different from  
accounts-example.com.  When both name alterations become common, this  
might actually increase a spoofing risk.  What sub-domains should be  
trusted?  The parent or the sub-domain?  What if the sub-domain is  
signed by the parent?

-Doug

---

From: John Levine <[email-masked]>
Date: 27 Jul 2006 06:29:06 -0000

>have reputation services distinguish between one domain+selector and another.

If you're thinking about the DAC stuff at domain-assurance.org, our
current spec is for certification, not reputation.  A critical
difference is that certification is done with the cooperation of the
certify-ee.  This means that the certifier can have inside info about
the way the certified domains uses its selectors, so they can say that
they vouch for this set of selectors that this part of the company
uses to send its kind of mail, but not the rest of the company.  The
message types are sender assertions that the mail using those
selectors is supposed to be transactional or whatever, so if you see
mail of some other type, someone's lying.

Reputation systems can't make those assumptions, and I agree that
there's a lot less you can do with a selector.  I suppose a reputation
system might be able to say "here's our opinion of the mail we've seen
so far with this selector", but I don't see any way to tie selectors
to message types without the sender's cooperation.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jul 2006 05:49:16 -0700

John Levine wrote:
> current spec is for certification, not reputation.  

1. I was focused on use of selectors for semantic purposes and was not trying to
refer to any particular semantics.

2. I used the term "reputation" because it has the widest use.

3. If you can show me industry-wide consensus on the definitions of terms such
as reputation, certification, and accreditation I will be extremely interested
to see it.  My own observation is that it does not exist.  So while you have
your precise usages, other people have theirs, and they are different.  Each use
of precise terminology might indeed be highly careful and make quite a bit of
sense, but the most important issue is that they are different from each other.

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jul 2006 05:55:40 -0700

> Someone said that protocol abuse, defined success. Was that you Dave?

No, but I like it.  It fits with other characteristics of an expanding
population of adopters and users.  More variability.

> stop it in the protocol, at best we can write unread admonishments.

At best, we can write some admonishments that get read.  That's why a BCP or
O'Reilly type of guide would be useful.

d/

-- 

  Dave Crocker