Subject: [Asrg] Third party DKIM signatures

From: "John R Levine" <[email-masked]>
Date: 21 Apr 2006 08:57:53 -0400

DKIM lets anyone sign any message, with no necessary connection between
the signing domain and the domain in any other header such as From: or
Sender:.  By third-party signatures we mean signatures that don't match
the From: or don't match the Sender:, or don't match something else.

The semantics as well as definition of third party signatures are, to put
it mildly, somewhat unclear.  Some thought or actual experiments with such
signatures could be helpful.

Pat Peterson and Doug Otis expressed interest in this item.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Apr 2006 08:39:01 -0700

> Pat Peterson and Doug Otis expressed interest in this item.

Here is a description of an approach that could be used to associate
third-party signatures with signing-domains.  This draft describes the
technique.

http://www.ietf.org/internet-drafts/draft-otis-smtp-name-path-00.txt

This technique is intended to provide a comparison with other testing.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Apr 2006 11:59:32 -0700

> the From: or don't match the Sender:, or don't match something else.
The definition in the current SSP draft is that a third-party signature
is a signature that doesn't match the From:.  There is no reference to
Sender: or "something else".
> signatures could be helpful.
I have done a lot of thinking about this; other thought or experiments
welcome.  Given that SSP is the next document up for discussion in the
DKIM WG, I think this has progressed beyond "research", and I don't
think it's a good idea to fragment discussion between this mailing list
and that one.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Apr 2006 13:07:37 -0700

On Apr 24, 2006, at 11:59 AM, Jim Fenton wrote:

> John R Levine wrote:
>> DKIM lets anyone sign any message, with no necessary connection  
>> between the signing domain and the domain in any other header such  
>> as From: or Sender:.  By third-party signatures we mean signatures  
>> that don't match the From: or don't match the Sender:, or don't  
>> match something else.
>>
> The definition in the current SSP draft is that a third-party  
> signature is a signature that doesn't match the From:.  There is no  
> reference to Sender: or "something else".

This detail is still open, as SSP is at an early stage of development  
where details covered in the SSP raise concerns.

>> The semantics as well as definition of third party signatures are,  
>> to put it mildly, somewhat unclear.  Some thought or actual  
>> experiments with such signatures could be helpful.
>
> I have done a lot of thinking about this; other thought or  
> experiments welcome.  Given that SSP is the next document up for  
> discussion in the DKIM WG, I think this has progressed beyond  
> "research", and I don't think it's a good idea to fragment  
> discussion between this mailing list and that one.

The DKIM WG are dealing with the Base draft and there is a desire to  
postpone SSP related discussions.  Similar concepts discussed here  
should not cause any fragmentation at this time.

Concepts dealing with both DoS and message replay abuse concerns  
could be found with a strategy to make associations between the  
originating source (from/sender/resent-from/resent-sender) and the  
signing-domain.  Associations are practical for a substantial portion  
of the email traffic (including DKIM related traffic) without  
incurring a high level of DNS transactions while also providing a DoS  
protection strategy.  The current draft SSP draft neglects to offer  
such associations or protective strategies.

This draft offers a possible approach.
http://www.ietf.org/internet-drafts/draft-otis-smtp-name-path-00.txt

What is not covered in this example is a specific association between  
an originating source and a DKIM signature.  This association is  
assumed to provide both the third-party EHLO _and_ DKIM signature  
authorization list.  Purists may desire a specific PTR list such as  
_tps._smtp.<example.com> to define an explicit list of what domain is  
allowed to sign messages for a specific domain and not just transmit  
(if that really matters).  A special domain label was also not  
created to indicate no email is allowed.  This could be a domain of  
'-.' that indication no mail association, for example.  A list, in  
addition to making explicit associations, also defines the nature of  
list, negating a need for the current SSP syntax that does this sans  
any associations.

Rather than raising issues specific to just DKIM, this strategy  
relates to a broader class of emails, while also providing DKIM  
relevant protective strategies.

-Doug