Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures

From: Alessandro Vesely <[email-masked]>
Date: Sat, 01 May 2010 16:56:50 +0200

On 30/Apr/10 20:22, John Levine wrote:
> Is there some long-standing toxic effect of mailing lists other than
> that they don't fit the simple identity models used by recently
> devised authentication schemes?

The opt-in mechanism, I'd say. There's no standardized way for 
subscribers' servers to learn about subscriptions. Monthly reminders 
resemble a time-distributed database w.r.t. what could be provided 
otherwise. (Not to mention whitelisting.)

-- 
I set the footer, in order to check whether signatures without "l=" 
would have a chance to survive, if they weren't stripped: if it ends 
up doubled, they wouldn't.

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

---

From: Douglas Otis <[email-masked]>
Date: Sat, 01 May 2010 09:39:40 -0700

> otherwise. (Not to mention whitelisting.)
The only exchange necessary would be checking the sender's domains for 
authorization hash labels.  These labels can specifically authorize list 
traffic.

-Doug

---

From: John Levine <[email-masked]>
Date: 1 May 2010 23:01:13 -0000

>subscribers' servers to learn about subscriptions.

Even if you consider that to be a problem, what could it possibly have
to do with DKIM?

There's always the option of using RSS to pull messages from a list,
and avoiding the list->subscriber mail link altogether.  Many MUAs
make an RSS feed look just like mail from a list.  (Responses to this
part to ASRG, please, since it's unrelated to DKIM.)

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 02 May 2010 12:10:41 +0200

> Even if you consider that to be a problem, what could it possibly have

Just that if there were a handshake between a list server and a new 
subscriber's MX, they could also agree upon ADSP forwarding, e.g. by 
whitelisting the list server.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sun, 02 May 2010 12:33:31 +0100

> whitelisting the list server.
To retain security, the sender's domain needs to assert domain specific 
exceptions for "all" or "discard-able" ADSP policies.

Someone subscribed to a mailing list does not mean the list then has any 
purported sender's blessing to make exceptions, especially when some 
lists don't prevent simple spoofing.  From a security stand point, it 
would also be unwise to have automated exchanges with mailing-lists 
prompted by receipt of messages needing exceptions.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 03 May 2010 09:58:08 +0200

> exceptions for "all" or "discard-able" ADSP policies.

That's false, under several acceptations of "security". /Necessity/ of 
such assertions only makes sense if "security" is meant to be the 
ability of a domain to restrict legitimate uses of its name, such as 
its users writing to mailing lists, or to their grandma's.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 04 May 2010 15:00:08 +0100

> its users writing to mailing lists, or to their grandma's.
ADSP "all" or "discardable" with specific third-party authorizations by 
a sender's domain does not restrict who may receive their message.  This 
relates to who is trusted to modify the sender domain's messages.  
Lacking a valid signature,  specific third-party authorizations permit 
enhanced security for recipients while avoiding message loss.

Sender's specific third-party domain authorizations indicate trust in a 
third-party service not to make malicious modifications.

When a sender has not found their messages spoofed to mislead their 
recipients, they may not see value in making ADSP "all" or 
"discard-able" assertions.

When a domain's messages are being spoofed to mislead recipients, there 
is no reason to expect spoofing will be limited to transactional 
messages.  As such, greater security becomes possible without disrupting 
services by including a specific third-party authorization mechanism.

Rather than separately signing third-party authorizations within a 
message using headers that might be stripped, there would be less 
overhead and greater conformance permitted when retrieving a hashed 
label from the sender's domain.  This would permit use of F2F services 
that were specifically authorized.  DNS has a DNAME resource record, 
that when published at the _adsp node, can synthesize CNAMEs when needed 
to permit a vouching service a means to assert authorizations on behalf 
many other sender domains.  Of course, each sender domain could 
selectively authorize third-party services being used as well.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 05 May 2010 16:36:50 +0200

> relates to who is trusted to modify the sender domain's messages.

I agree with the overall concept, but I don't like it stated that 
way. In general, recipients may trust third parties independently of 
the originating domain.

A naive interpretation of DKIM may consider it has done its job when 
the message has been received and verified. But where's the limit? 
Besides lists and grandma's broken forwarder, consider ticketing 
systems, archiving software, any ad-hoc filter (e.g. scripts 
designed for specific transactions, that add their results to the 
body of the message itself) and even manual modifications by the 
recipients. In all these cases, one obviously doesn't want to alter 
the From: for the sole sake of ADSP.