Subject: Re: [ietf-dkim] SSP - should r= be localpart only?

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Feb 2006 18:35:22 -0800

On Feb 16, 2006, at 6:11 PM, Mark Delany wrote:

> Not that I know when r= should be used, but, it strikes me that  
> having an r= specify an address outside of the domain in question  
> is a potential for DOSing some innocent third-party.
>
> So, should r= only specify a localpart and the domain is implied by  
> the domain being queried, or if r= specifies a complete address,  
> should the domain be constrained to be in the policy query domain  
> or below?

Remember, the SSP policy is referenced from an email-address.  Having  
the 'r=' parameter within the SSP policy is already suspect.  When  
the message is signed by a third-party, what can an email-address  
domain owner do when a problem is being reported?  The _only_ entity  
able to take corrective action would be the signing-domain, as they  
control access.  Reporting problems to a hapless entity will easily  
result in a DoSing, as they have no ability to take corrective action  
to block the miscreants.  The localpart should be limited to that of  
the signing-domain, which means it does _not_ belong in the SSP record!

There should only be an 'r=' parameter within a record referenced  
from the signing-domain.  For that matter, an address convention may  
handle the requirement.

-Doug

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

---

From: Mark Delany <[email-masked]>
Date: Fri, 17 Feb 2006 02:11:22 +0000

Not that I know when r= should be used, but, it strikes me that having
an r= specify an address outside of the domain in question is a
potential for DOSing some innocent third-party.

So, should r= only specify a localpart and the domain is implied by
the domain being queried, or if r= specifies a complete address,
should the domain be constrained to be in the policy query domain or
below?

Mark.

---

From: SM <[email-masked]>
Date: Fri, 17 Feb 2006 05:32:14 -0800

Hi Mark,
>potential for DOSing some innocent third-party.

"r=" is used for reports and inquiries regarding the signing 
policy.  Currently, there is no restriction on the email address for 
that tag.  Some implementations of DKIM send out an automated message 
to notify the signer of verification failures.  There is a well-known 
domain which sends out an automated reply on receipt of messages to 
the reporting email address.  The "r=" tag can easily be misused.

>should the domain be constrained to be in the policy query domain or

The "r=" tag should be restricted to email addresses within the SSP 
domain being queried.  The host part of the email address should be 
constrained to be within the SSP domain.  You can then use email 
addresses such as [email-masked] or [email-masked].

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Feb 2006 11:06:38 -0800

On Feb 17, 2006, at 5:32 AM, SM wrote:
> "r=" is used for reports and inquiries regarding the signing policy.

1) With an open-ended policy, 'r=' referenced from the email-address  
domain will still create havoc.

2) When the signing policy is closed, the email-address and the  
signing-domain are synonymous, but email is broken.

3) Only the signing-domain can effectively respond to abuse reports.

4) 'r=' should only be referenced from the signing-domain.

> Some implementations of DKIM send out an automated message to  
> notify the signer of verification failures.

Should these reports go to the email-address domain owner or to the  
signing-domain?  Who can fix the problem?

> The "r=" tag can easily be misused.

Agreed.  If there are to be reports allowed, these should be reports  
to the entity able to take corrective action, the signing-domain.

>> So, should r= only specify a localpart and the domain is implied  
>> by the domain being queried, or if r= specifies a complete  
>> address, should the domain be constrained to be in the policy  
>> query domain or below?
>

A restriction limiting reports to the email domain will not prevent  
abuse.  Do not assume closed policies are in place.  Do not use this  
reporting mechanism as a method to punish email-address domain owners  
not publishing closed policies.  When the only logical choice for  
open-policies is to not use 'r=' email-address vector, how does one  
still allow a means to report abuse to the signing-domain?

-Doug

---

From: SM <[email-masked]>
Date: Mon, 20 Feb 2006 10:02:27 -0800

Hi Douglas,
>signing-domain?  Who can fix the problem?

The r= email address is for reports and inquiries about the signing 
policy only.

>to the entity able to take corrective action, the signing-domain.

Reports are useful in the testing phase to detect broken signatures 
at the verifier's end.  We cannot "trust" the email from the 
signing-domain if it fails verification which makes sending the 
reports questionable.

>still allow a means to report abuse to the signing-domain?

The "r=" tag is optional.  Publishing it is not asking for 
punishment.  It is to allow the signer to take corrective 
action.  The restriction limits the scope for a denial of service.

The "r=" tag is not for reporting abuse.  I used "[email-masked]" 
as an example only.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Feb 2006 11:00:17 -0800

On Feb 20, 2006, at 10:02 AM, SM wrote:
>> Should these reports go to the email-address domain owner or to  
>> the signing-domain?  Who can fix the problem?
>

What action is expected of the email-address domain owner when making  
the report?

>> Agreed.  If there are to be reports allowed, these should be  
>> reports to the entity able to take corrective action, the signing- 
>> domain.
>

The signing-domain _may_ wish to receive broken signature reports;  
they could compare these against message destinations.  It is  
unlikely the email-address domain owner would be able to effectively  
deal with reports of third-party signature failures, or to be able to  
take corrective actions.

>> A restriction limiting reports to the email domain will not  
>> prevent abuse.  Do not assume closed policies are in place.  Do  
>> not use this reporting mechanism as a method to punish email- 
>> address domain owners not publishing closed policies.  When the  
>> only logical choice for open-policies is to not use 'r=' email- 
>> address vector, how does one still allow a means to report abuse  
>> to the signing-domain?
>
> punishment.  It is to allow the signer to take corrective action.

If this report is expecting the signer to take corrective action,  
then by all means, the report vector _must_ be referenced from the  
signing-domain and _not_ the email-address domain as it is now!   
Reports _must_ assume DKIM holds the _signing-domain_ accountable.   
When there are problems, the _signing-domain_ should know about  
problems created by the messages they sign.  Referencing the report  
vector off of the email-address domain ignores completely who signed  
the message!

> The restriction limits the scope for a denial of service.

When reports are sent to hapless email-address domain owners who are  
unable to take corrective actions, there is _no_ means to prevent  
these report vectors from creating a DoS.

> The "r=" tag is not for reporting abuse.  I used  
> "[email-masked]" as an example only.

The recipient decides what they wish to report and abuse will likely  
be high on their list.  Even broken signatures by third-parties seems  
an unlikely a problem to report to the email-address domain owner.   
Assuming there is corrective action that can be taken to repair some  
incompatibility, it would be the signer, and not the email-address  
domain owner, that would be able to make the corrections.

-Doug

---

From: SM <[email-masked]>
Date: Tue, 21 Feb 2006 21:47:55 -0800

Hi Douglas,
>What action is expected of the email-address domain owner when making

It is to take whatever corrective action the person deems it necessary.

>signing-domain and _not_ the email-address domain as it is now!

The issue you raised is about reports to the signer.  The question 
asked in this thread is whether the "r=" tag should be localpart 
only.  As I see it, the "r=" tag is about  the signing policy for the 
domain.  The alternatives are:

1. Restrict the tag to localpart

2. Restrict the tag to hosts within the domain

3. Remove the tag.

Regards,
-sm

---

From: Mark Delany <[email-masked]>
Date: Wed, 22 Feb 2006 06:48:54 +0000

> 2. Restrict the tag to hosts within the domain

A comprehensive set of choices. The one thing missing is your
recommendation. Do you wish to share?

Mark.

---

From: SM <[email-masked]>
Date: Wed, 22 Feb 2006 07:57:10 -0800

Hi Mark,
>recommendation. Do you wish to share?

I posted the following suggestion a few days ago:

"The "r=" tag should be restricted to email addresses within the SSP 
domain being queried.  The host part of the email address should be 
constrained to be within the SSP domain."

Regards,
-sm

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 09:52:19 -0800

On Feb 21, 2006, at 9:47 PM, SM wrote:
>> What action is expected of the email-address domain owner when  
>> making the report?
>

While the signing-domain can take effective actions, please attempt  
to list the actions the email-address domain owner may take?

Consider the effect of only having report vectors referenced from the  
email-address domain, rather than the signing-domain who is able to  
take effective action to correct a full range of problems that might  
be reported.  Report references from the email-address domain  
unfortunately invites abuse reports when publishing open-ended  
policies.  When the email-address domain owner publishes an open- 
ended policy, the likely corrective action would be to remove the  
report tag.  So how does a signing-domain that also has an open-ended  
policy safely offer a report vector?  They can't.  So how does a  
email-address domain owner with an open-ended policy safely offer a  
report vector.  They can't either.

A report vector acquired from the signing-domain would concern _only_  
messages they have signed, and not messages that happen to contain an  
email-address within their domain.  For domains where use of their  
email-address is critical, they will exclusively sign their own  
messages, which makes obtaining the report vector from the signing- 
domain an equivalent outcome.  Having a report vector acquired from a  
signing-domain reference is the _only_ safe and reasonable means to  
provide this reporting feature and still permit open-ended policies.

-Doug

---

From: SM <[email-masked]>
Date: Wed, 22 Feb 2006 11:42:07 -0800

Hi Douglas,
>to list the actions the email-address domain owner may take?

I said that the domain owner may take any action deemed necessary. 
:)  The owner is responsible for the signing policy and may wish to 
determine the impact of the policy.

>be reported.  Report references from the email-address domain

This discussion seems to be about "Should we have an r= tag in either the
signature or key record"

>email-address within their domain.  For domains where use of their

Are you talking about reporting DKIM signatures that cannot be 
verified?  If so, I don't see how you can trust the report vector 
acquired from the signing-domain.

Regards,
-sm

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 15:01:36 -0500

----- Original Message -----
From: "SM" <[email-masked]>

> This discussion seems to be about "Should we have an r= tag in
> either the signature or key record"
>
>> A report vector acquired from the signing-domain would concern
>> _only_ messages they have signed, and not messages that
>> happen to contain an email-address within their domain.  For
>> domains where use of their

> acquired from the signing-domain.

IMO, its not as much an issue of trust, it could be a form of attacks, but
so about rather operations.

What are the report limits?  Is the report-domain paying the validator to
send reports, because if not, it could be pretty costly.

I believe there are few implementations in SPF with reporting logic and I
believe it uses some limits in report/notification. If the notification is
not confirmed, then the domain is blocked in future failed transactions.

Similar hindsight will be required for DKIM as well if this r= feature is to
be part of the specs.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 14:07:11 -0800

On Feb 22, 2006, at 11:42 AM, SM wrote:
>> While the signing-domain can take effective actions, please  
>> attempt to list the actions the email-address domain owner may take?
>
> The owner is responsible for the signing policy and may wish to  

Could you describe how this would work, and what would be reported?   
Hand waving does not help.

>> Consider the effect of only having report vectors referenced from  
>> the email-address domain, rather than the signing-domain who is  
>> able to take effective action to correct a full range of problems  
>> that might be reported.
>

The 'r=' tag does no belong in the signing policy record, as this  
will only invite abuse.  However there is not enough space within the  
key as it is now.  Adding a report vector to the key would only make  
this problem worse.  As these are public email-addresses in the  
signing policy records, there would be few advantages over simply  
having a convention such as dkim-postmaster@.  If the key used a  
different RR record type from a RR that stored the report vector at  
the same location as the key, then there would be an advantage.   
Unless someone received a message from the domain, they would not  
know where to look for the report vector.  : )

>> _only_ messages they have signed, and not messages that happen to  
>> contain an email-address within their domain.
>

If the key selector located the report vector, this could be one  
reason to trust the message over that of just some anonymous message  
with a bad signature.

-Doug

---

From: SM <[email-masked]>
Date: Thu, 23 Feb 2006 21:52:54 -0800

Hi Hector,
>so about rather operations.

Agreed.

>send reports, because if not, it could be pretty costly.

The validator decides whether to send reports or not.  Note that I am 
not suggesting that automated reports should be sent or that this tag 
should be used for them.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Thu, 23 Feb 2006 22:21:13 -0800

Hi Douglas,
>Hand waving does not help.

Is the SSP policy of the domain I'm using affecting the delivery of 
mail?  If so, use the email address specified in the "r=" tag to report it.

>key as it is now.  Adding a report vector to the key would only make

I mentioned three alternatives in my previous email; one of which was 
to remove the tag.

Regards,
-sm

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Feb 2006 16:17:59 -0500

>> What are the report limits?  Is the report-domain paying the validator
>> to send reports, because if not, it could be pretty costly.
>

Right, my only point was to highlight necessary wording for the
specification describing the issues related to this tag (r=).

Mainly, in general, domains should not depend nor expect validators to honor
this reporting tag unless there is a special "contract" between them to
obtain this valuable feedback.

The specs currently say:

|   r= Email address for reports and inquiries regarding the signing
|      policy for this entity (plain-text; OPTIONAL, default is no
|      contact address available).

Additional text along the following thought process SHOULD|MUST be needed:

       Validators are not obligated to honor this signer reporting tag,
       nor obligated to send reports to the signing domain.

Maybe adding one sentence or short paragraph explaining the security
reasons.