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

From: Douglas Otis <[email-masked]>
Date: Mon, 1 May 2006 11:38:04 -0700

On Apr 29, 2006, at 4:23 PM, John R Levine wrote:

>> The text for the r= parameter indicated that as the number  
>> increases, 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.

The r= parameter would allow the signer to assist the recipient in  
distinguishing between well vetted, and poorly vetted sources.   
Without this parameter, or a similar mechanism, the use of different  
signing-domains would be needed to make such distinctions.  The use  
of different domains represents a very bad practice that would  
further enable message spoofing.  The increased use of similar domain  
names would erode the recipient's ability to recognize who they are  
trusting.  The r= parameter permits a consolidation of sources having  
various levels of vetting, while still permitting the signer to offer  
guidance which sources have undergone minimal vetting and retain  
trust for select sources.

Even when "trust" annotations are limited to signing-domain's trusted  
by the recipient, the recipient should also be able to exclude  
messages from receiving "trust" annotations when the signer also  
warns that the source has not been well vetted.   Having a mechanism  
for the signer to indicate which messages are from well vetted  
sources overcomes risks associated with the recipient's inability to  
recognize purported originating email-addresses contained within the  
message.

Message annotation will become critical when international domain  
names and local-parts are commonly used.  DKIM does not require that  
signers exclude messages because an email-address domain is different  
from that of the signing-domain.  It should also be acceptable that a  
trusted signing domain differs from that of an email-address  
contained within the message.

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

A signer can be highly responsible and _still_ sign messages from  
poorly vetted sources.  Otherwise, most email could not be signed.  A  
signer indicates who is accountable and who should disable abusive  
accounts when abuse is reported.  A signing domain may be very  
responsible, and yet sign messages from poorly vetted sources.  The  
r= parameters permits these responsible domains to sign "trusted"  
messages and to also sign less trustworthy messages.  It is not  
practical to consider all signed messages represent a uniform level  
of trustworthiness, or that the recipient can distinguish purported  
originating email-addresses.  The need for trust is important,  
especially when some messages request various actions that would be  
highly dangerous when acted upon from less trustworthy sources.   
Annotation is already required to assist the recipient distinguishing  
which messages are signed.  This same annotation can also warn when  
the source of the message has been poorly vetted by the signer.

How can a responsible signing domain better protect their recipient's  
than by using an r= parameter?

-Doug

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

---

From: John L <[email-masked]>
Date: Mon, 1 May 2006 15:00:15 -0400 (EDT)

> distinguishing between well vetted, and poorly vetted sources.

Only if the recipient has some extra info about what meaning a particular 
signer gives to its r= codes, which in general will not be the case.  Or 
if the recipient does know something extra about the signer, they can make 
any private arrangements they want, so there's no need to put anything in 
a standard.

>> 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.
>
> A signer can be highly responsible and _still_ sign messages from poorly 
> vetted sources.  Otherwise, most email could not be signed.

Hey, please don't change the topic.  The point of a DKIM signature is that 
the signer is taking responsibility for the mail.  I am most emphatically 
not intrested in trying to peer inside and analyze the entrails of their 
internal processes.  That's not what DKIM is about.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 1 May 2006 16:57:17 -0700

On May 1, 2006, at 12:00 PM, John L wrote:
> Only if the recipient has some extra info about what meaning a  
> particular signer gives to its r= codes, which in general will not  
> be the case.  Or if the recipient does know something extra about  
> the signer, they can make any private arrangements they want, so  
> there's no need to put anything in a standard.

Okay, 0-9 may be far too many to arrive at a well understood  
interpretation.  Following the example of the x-priority header, also  
used ubiquitously for message annotation, three levels seems a basic  
minimum.

The default assignment when r= is not included, would be r=1  
(normal).  An r=0 (low) level serves as a warning by the signer that  
the source or the content of the message has not been fully vetted.   
Alternatively, an r=2 (high) level indicates that both the source and  
the content of the message have been well vetted.  When the signing  
domain is trusted, the recipient may better rely upon information  
within the message when the signer also offers an increased reliance  
level.  Conversely, the signer offering a lowered reliance level  
could serve as a necessary warning.

0= low
1= normal (default)
2= high

: The r= parameter is assigned by the signer a value of
: 0-2, where 1 is the default, which recommends a normal
: reliance level be assigned the message for purposes of
: annotation.  An annotation of level 0 is to warn the
: recipient to place less reliance upon the information
: contained within the message.  An annotation level of 2
: indicates a higher level of reliance can be placed upon
: the information contained within the message.
:
: To ensure control in the case of MUA signing, the r=
: parameter in the signature MUST always be less than or
: equal to the key r= level.  When there is no r=
: parameter found in the key, the highest r= parameter
: allowed in the signature would be r=1.  When there are
: no r= parameters found within the signature, r= defaults
: to a level of 1.   An instance where the key r=
: parameter is less than that of the signature, the
: signature is invalid.

The signature provides an accountable domain when abuse is detected.   
When the signature encompasses a range of sources where some are  
poorly vetted, the signature, by itself, can not impart any  
additional level of trust, nor is it reasonable to expect recipients  
to recognize or independently vet email-addresses contained within  
messages.  Elevated reliance upon an email-address above that of the  
signing-domain would require several unsafe and unverifiable  
assumptions.

For example, an ISP may sign all messages.  When those messages are  
not authenticated from known good accounts, the provider may wish to  
warn recipients by asserting an r=0.  When the ISP wishes to  
recommended actions that might be considered dangerous when from  
untrustworthy sources, the ISP may wish to offer an r=2 to assure  
their customers that acting upon the information should not be  
considered a security risk.  The ISP may also caution customers not  
to act on account or system related requests that are not signed by  
them with an r=2 level.  Without the r= convention, greater  
constraints upon email-addresses would be required, and additional  
domains names would be needed to make distinctions of relative  
trust.  Email-address constraints may be disruptive, and additional  
domain names diminishes the goal at reducing the level of spoofing.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Tue, 2 May 2006 00:08:39 +0000

> Okay, 0-9 may be far too many to arrive at a well understood  

Colo[u]r me confused, but I don't see what this has to do with the
base function of a domain claiming responsibility. Is this r= thing
fundamental to that function or could it be developed as a separate
exercise above and beyond the base? After all, the whole point of the
tag=value syntax is so that additional functionality can be seamlessly
added on.

If r= is non-essential, then can we leave those discussions until
after the base work is done, otherwise it's just hindering us.

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 1 May 2006 19:07:19 -0700

On May 1, 2006, at 5:08 PM, Mark Delany wrote:
> base function of a domain claiming responsibility.

While the signer may be expected to react in cases of abuse, the base  
DKIM signature mechanism does not safely impart trust above the least  
trustworthy source being signed by the domain.  It remains doubtful  
how effective a reaction to abuse will be, for that matter.  Whether  
for messages from financial institutions or an ISPs, additional  
protection is required to both protect and retain the recipient's  
trust of messages being signed by a domain.  The DKIM signature  
should not be considered to provide a good reactive mechanism, but it  
can be a good proactive mechanism.

> Is this r= thing fundamental to that function or could it be  
> developed as a separate exercise above and beyond the base?

A wait in establishing a means to protect trust (based upon message  
annotation or filtering) may invoke a reaction to this limitation  
that could prove highly counter-productive.  The need for the added  
protection related to trust easily exceeds that of the x= parameter,  
in comparison.  Without a means to segregate sources of differing  
levels of trust or vetting, the only remaining alternative would be  
to utilize additional domain-names.  A reaction, due to this  
protective oversight, may produce a plethora of similar domain- 
names.  These additional domain names may actually result in phishing  
being even more lucrative, rather than being abated by the DKIM  
signature. : (

> After all, the whole point of the tag=value syntax is so that  
> additional functionality can be seamlessly added on.

The r= parameter, as just described, can be incorporated as an option  
when needed, in the same manner as the x= parameter.  For many, the  
additional annotation may not be needed.  In critical cases however,  
this r= annotation may prove vital at preventing rather dangerous  
exploits, and rather bad practices.  The real value of DKIM is found  
proactively establishing trust for selected messages from trusted  
domains.  In many, if not most cases, trust is better assured by  
offering an assured means to select messages.  It remains doubtful  
such selection can be achieved through the recognition of email- 
addresses.

> after the base work is done, otherwise it's just hindering us.

A good point.  There is no desire to hinder progress for non-critical  
concerns.  The r= parameter, or something similar, should be provided  
at the outset to avoid the proliferation of "segregated" domain  
names, a critical concern.  While companies such as yahoo have dealt  
with the problem of diminished trust of their well-known domain name  
by employing additional domain names, such as yahoo-inc, this  
strategy should be viewed as a bad practice when abating a phish  
threat.  The r= parameter provides an alternative to the use of  
different domain names when segregating sources.  Hopefully  
describing just three levels low (as a warning), normal, and high (as  
an assurance) is something easily understood and yet still provides a  
feasible alternative to segregating domains.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Tue, 2 May 2006 03:30:11 +0000

On Mon, May 01, 2006 at 07:07:19PM -0700, Douglas Otis allegedly wrote:

> >Is this r= thing fundamental to that [verification] function or
> >could it be developed as a separate exercise above and beyond the
> >base?

> A good point.  There is no desire...

Doug. As far as I can tell, your 420 word reply said neither yes or
no. But to be frank, I stopped reading after the second
paragraph. Sorry.

The good news is that the first 100 words seemed like they were
trending towards a no, so I'll run with that.

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 May 2006 09:44:54 -0700

> trending towards a no, so I'll run with that.

There remains a serious, but easily corrected, limitation with the  
basic DKIM mechanism that threatens retention of trust for specific  
sources within a signing-domain.  This limitation should be overcome  
at the outset to avoid a counter-productive practice that employs  
additional domain names as a means to isolate less trustworthy  
sources.  It would be an unfortunate oversight that reduces security  
and safety by not permitting the signer a means to identify specific  
trustworthy sources within a common domain.

-Doug