Subject: [ietf-dkim] r= for instilling good domain-name practices

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Apr 2006 10:10:15 -0700

A major objective of DKIM is to uncover spoofed messages.  Often the  
well-known domain-name establishes trust in messages.  Atlas, not all  
messages from well-known domain-names are always fully vetted, and  
currently DKIM offers _no_ information on the level of vetting used  
by the well-known domain-name for the source of the message.  Some  
have suggested sub-domains can isolate sources of differing vetting  
levels.  Some have adopted similar looking hyphenated domain-names.    
Unfortunately, both practices will not indicate to the recipient  
which domain-name should be trusted.  The resulting profusion of  
additional domain-names stemming from this glaring over-sight only  
increases the likelihood of people being duped, thwarting the major  
objective of DKIM.

DKIM already has an x= parameter designed to limit the time interval  
of trust defined by the sender, over-riding the time intervals used  
by recipients.  There is unfortunately no r= reliance parameter.  The  
r= parameter can prevent a dangerous reaction where a number of  
additional domain-names are deployed in an effort to restore trust  
when damaged by poorly vetted sources.  The r= parameter would allow  
10 separate levels of trust to be accommodated by a single well-known  
domain.

: The r= parameter is defined by the signer as a simple number
: of 0-9, where 0 is the default offering the lowest reliance
: level.  To ensure control in the case of MUA signing, this r=
: parameter in the signature MUST always be less than or equal
: to the key r= level.  If there are no r= parameters found in
: the key, the highest r= parameter allowed in the signature
: would be r=0.  An instance where the key r= parameter is less
: than that of the signature, the signature is invalid.

At some later date, conventions for the assignment of the reliance  
parameter, and the type of related message annotations could be  
included in a BCP document.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 28 Apr 2006 17:45:25 -0700

> : than that of the signature, the signature is invalid.

One signer's r=3 might connote a level of verification equivalent to 
another signer's r=8.  So as a recipient, I'd have to keep track of the 
domain, the selector, AND the r value...even though I'll be making my 
reputation decision based entirely on criteria of my own choosing.  So, 
I might as well just ignore the r value.

You're trying to fit reputation policy -- which is a sociopolitical 
issue -- into a technical standard.  A peg of infinite dimensions into a 
hole of intentionally finite dimensions.  The likelihood that it'll fit 
is infinitely small.

-- 
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: Michael Thomas <[email-masked]>
Date: Fri, 28 Apr 2006 18:19:47 -0700

J.D. Falk wrote:

> another signer's r=8.  So as a recipient, I'd have to keep track of 
> the domain, the selector, AND the r value...even though I'll be making 
> my reputation decision based entirely on criteria of my own choosing.  
> So, I might as well just ignore the r value.

Right. One lingering concern that I had is that a large domain like, oh say,
Yahoo! might not have very good control over some of its population, thus
diluting its reputation. But with the selector segregation, you just put the
riff-raff in their own part of the namespace, the corpro-spammers in theirs,
etc, etc, giving the necessary hooks for somebody to hang different 
reputations
on. Problem solved; r= brings nothing more to the table because I don't
trust anything positive a signer  says anyway.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Apr 2006 18:41:31 -0700

On Apr 28, 2006, at 5:45 PM, J.D. Falk wrote:

> One signer's r=3 might connote a level of verification equivalent  
> to another signer's r=8.  So as a recipient, I'd have to keep track  
> of the domain, the selector, AND the r value...even though I'll be  
> making my reputation decision based entirely on criteria of my own  
> choosing.  So, I might as well just ignore the r value.

Without conventions established for the use of this parameter, it  
will offer only little value.  Without conventions, only the reliance  
parameter being greater than zero would be of any significance.   
Conventions can recommend reliance levels for various types of  
sources such as:

Administrators		9
Transactional email	8
Permanent Employees	7
Automated messages	6
Mailing lists		5
Domain Users		4
Bulk			3
Proxy Service		2
Transparent Service	1
Guests			0

With this type of list, a recipient wishing to annotate messages  
would have a far better idea what level of reliance could be placed  
upon a range of messages from an otherwise trusted and well-known  
domain.  Not all messages are trustworthy, even from a well-known  
domain.  Perhaps as a general practice, all domains would default to  
receiving elevated annotation when exceeding a level of 5.

> issue -- into a technical standard.

This is _not_ about reputation.  This is confronting the issue that  
not all messages from well-known domains are equally vetted.  This  
mechanism simply allows the well-known (and otherwise trusted domain)  
to characterize the level of vetting that has been given their  
sources.  (Of course there would be greater damage to their  
reputation should abuse be signed at a high level of reliance.)

This mechanism is to head off a highly counter-productive strategy  
that adopts a plethora of domain-names that attempt to make these  
same types of distinctions.  Such a strategy further increases the  
number of look-alike domains and perhaps overwhelm the average  
consumer, while also greatly diminishing brand recognition.  Brand  
recognition is of tremendous value and is being protected by this r=  
mechanism.  If DKIM is to curtail the success of phishing attempts,  
this r= (or something like it such as selector tagging) is vitally  
needed.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Sat, 29 Apr 2006 08:38:33 +0200

Doug,

>
> Without conventions established for the use of this parameter, it will
> offer only little value.  Without conventions, only the reliance
> Conventions can recommend reliance levels for various types of sources
> such as:
>
> Administrators        9
> Transactional email    8
> Permanent Employees    7
> Automated messages    6
> Mailing lists        5
> Domain Users        4
> Bulk            3
> Proxy Service        2
> Transparent Service    1
> Guests            0
>
> With this type of list, a recipient wishing to annotate messages would
> have a far better idea what level of reliance could be placed upon a
> range of messages from an otherwise trusted and well-known domain. 
> Not all messages are trustworthy, even from a well-known domain. 
> Perhaps as a general practice, all domains would default to receiving
> elevated annotation when exceeding a level of 5.

This seems to me to be a poor man's version of SSP, and I would think
that we would consider it in such a context.  But even if we were to
consider this now, wouldn't different selectors cover this ground?

Eliot

---

From: John Levine <[email-masked]>
Date: 29 Apr 2006 14:27:54 -0000

>This seems to me to be a poor man's version of SSP, ...

The whole issue of mail categories is an interesting one, but it's a
large, deep, chewy can of worms relevant to much more than DKIM that
we'd be nuts to try to address here.

Those of us who are nuts are welcome to reconvene in the ASRG where
it's already a topic of occasional discussion.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Apr 2006 10:52:37 -0700

> consider this now, wouldn't different selectors cover this ground?

It is unknown whether an SSP record can be discovered when investigating
email-addresses found within the message.  The DKIM signature is not
required to have any relationship with an email-address however, which
is good.

The possible independence of the email-address also means that when the
email-address's SSP allows third-party signing, SSP could be worthless
at establishing _any_ level of trust, even when the signer is well-know
and trusted and willing to vouch for the source.  The r= parameter would
allow the signing-domain far greater clout.  After all, the signing-
domain is where the trust _must_ be derived.  For many email-addresses,
SSP will offer _nothing_ in regard to trust.  There is real value in r=.

A selector tagging convention could be established, but it would not
offer as much flexibility as would the r= parameter.  A key selector can
not offer a range, where a common key could be used for different levels
of vetted sources when signed at the MTA, for example.  A key selector
also does not have any relative merit, which would need to be
established by convention.  A simple sequence of numbers already imparts
this relationship.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Apr 2006 11:03:46 -0700

> it's already a topic of occasional discussion.

Once the r= parameter is established as an option in the DKIM mechanism,
conventions for what is implied by the different levels of r= parameter
can, and perhaps should, be defined by other groups.

It is however vital that some standardize convention for expressing this
information be provided by the DKIM mechanism, or there is a real
possibility that DKIM will make the situation worse when signing domains
resort to using more domain names to distinguish between differ levels
of vetted sources.  This strategy would greatly weaken domain-name
recognition, and much of the value that could be derived by
incorporating DKIM signing. 

-Doug

---

From: John L <[email-masked]>
Date: Sat, 29 Apr 2006 14:40:30 -0400 (EDT)

> incorporating DKIM signing.

Since we don't know what the arguments to r= mean, I don't understand why 
r=xxx is better than xxx._domainkeys.foo.org, in both cases with an xxx 
that means nothing unless you happen to have a side agreement with the 
sender.

More to the point, systems to evaluate the reputation of a sender or 
signer are utterly, completely out of scope for the DKIM project.  As we 
keep reminding ourselves, a valid signature from foo.org means no more or 
less than "you can blame foo.org if you don't like this."

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Apr 2006 15:00:58 -0700

> that means nothing unless you happen to have a side agreement with the 

The text for the r= parameter indicated that as the number increases,
the recommended annotation levels made by the signer also increase.
With a selector, relative assurances do not exist.  A selector for this
purpose also requires that key selection be tied to the level of the
recommendation, where it may be simpler to add this as an independent
parameter, especially when messages are being signed at the MTA.

> signer are utterly, completely out of scope for the DKIM project.

The assurance being made by the signer has _nothing_ to due with
reputation.  This r= parameter relates to annotation recommendations
made by the signing domain for a particular message.  Within a
particular domain, some sources of messages will be considered by the
signing-domain as more trustworthy than others.  Only the signer can
reasonably make this indication.  With this parameter, the recipient
must still trust the signer, but the signer also indicates their level
of trust for the source, thus increasing security.

Perhaps this message is to inform customers about the availability of
recommended browser plug-ins.  It would be important for a responsible
signer that these messages not be confused with other messages that
might also be signed, but are from less well vetted sources.  Until
conventions are established, perhaps a general guideline could be
initially established of not offering elevated annotations for messages
with an r= level below 6.

> As we keep reminding ourselves, a valid signature from foo.org means
> no more or less than "you can blame foo.org if you don't like this."

This parameter is _not_ about reputation, it is about improving
security.  This r= parameter is a recommended trust-level annotation for
a message from an otherwise trusted, well-known domain.  Few, if any,
domains should be considered to only sign message from sources given
uniform vetting.  Whether this is a financial institution or a large
ISP, there are some sources within these domains that should _not_ be
annotated with a uniform level of trust.  The r= parameter allows the
signer a method to inform the recipient the level of trust the sender
recommends for the source of the message.

This r= parameter should prevent a practice of inventing oddly named
domains that attempts to make the same distinctions that can be far more
safely made using the r= parameter.  This parameter is not about
reputation, this is about safety and security.

-Doug

---

From: "John R Levine" <[email-masked]>
Date: 29 Apr 2006 19:23:11 -0400

> the recommended annotation levels made by the signer also increase.

Indeed, but we still have no idea how that translates into making a
reputation decision.

> made by the signing domain for a particular message.

Oh, in that case, I have no interest in r values less than infinity, and I
don't think anyone else should, either.  If a signer isn't prepared to
take responsibility for the mail they sign, they have no business signing
it.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Apr 2006 21:11:35 -0700

> issue -- into a technical standard.  A peg of infinite dimensions into 
> a hole of intentionally finite dimensions.  The likelihood that it'll 
> fit is infinitely small.

With some regularity, we have someone offering a proposal that gets no 
support, but still prompts people to post lots of responses.  This 
thread appears to be yet-another one of those.

Here is a simple suggestion:  When someone makes a proposal, those who 
disagree with it should wait until the proposal shows some signs of 
support from others.

Really.  It will dramatically cut down the noise on the list.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>