Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list?

From: Hector Santos <[email-masked]>
Date: Fri, 02 May 2014 20:35:45 -0400

Hi Fred,

We have already did all this. Over the last 9 years, we have produced 
all these DKIM related documents:

    RFC4686  Analysis of Threats Motivating DKIM
    RFC4870  DomainKeys
    RFC4871  DKIM (RFC5672.TXT,  RFC6376.TXT)
    RFC5016  Requirements for a DKIM Signing Practices Protocol
    RFC5451  Message Header Field for Indicating Message 
Authentication Status
    RFC5518  Vouch By Reference
    RFC5585  DKIM Service Overview
    RFC5617  DKIM Author Domain Signing Practices (ADSP)
    RFC5863  DKIM Development, Deployment, and Operations
    RFC5965  An Extensible Format for Email Feedback Reports
    RFC6376  DomainKeys Identified Mail (DKIM) Signatures
    RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists
    RFC6541  DomainKeys Identified Mail (DKIM) Authorized Third-Party 
Signatures

and that all doesn't include all the draft I-D produced by myself, 
Doug Otis and others.

We are well pass the hypothetical, theory, proof of concepts, etc. 
Mailing list Software with DKIM+POLICY support exists, at least ours does.

This is an issue of getting IETF endorsement to support the DKIM 
POLICY framework. The IETF just made ADSP RFC5617 historic earlier 
this year.  DMARC snuck in with large domains enabling the strong 
handing mode of operations.  That surprised the IETF and left the 
network not ready to handle this long known 9 year old DKIM+POLICY 
design/change requirement situation.  Other MLS software/operators 
need to adjust and so far, the IETF is not willing to accept a 
DKIM+POLICY framework the industry wishes to go with.

Overall, the two key changes are:

1) MLS checks/deny/notify new subscribers using restrictive policy 
domains.

2) MLS checks/deny/notify new submissions from restrictive policy 
domains list members.

Those two basic changes are needed in principle to honor the security 
policy first.

The hard part was how to scale author domain authorized 3rd party 
signers for author domain policies that allow resigning and this was 
pretty much where it was all left at, with 3rd party authorization 
proposals that piggy backed off the ADSP record with ATPS (RFC6541), 
my ASL (Authorized Signer List) proposal and Doug's TPA proposal. 
This is also where Levine's Whitelist suggestion can play a role, but 
it still needs to be author domain authorized.

I don't see us going anywhere unless a fundamental IETF acceptance for 
DKIM+POLICY occurs and that means honoring the security policy first, 
not ignore it and continuing to forward unauthorized resigned mail.

Unless the ADSP status can be reversed, and DMARC is here to stay, the 
IETF needs to update the DMARC document for 3rd party support.

Finally point, the example email attachment you had from 
[email-masked], keep in mind it does not have a DMARC policy, but it 
does a ADSP "dkim=all" which says that only the first party signer was 
expected in all mail.   But there is o reject/discard handling 
semantics as it would be for a "dkim=discardable" ADSP policy.

-- 
HLS

On 5/2/2014 2:05 PM, Fred Baker (fred) wrote:
> We have been having a fairly extended discussion, much of which seems hypothetical - �I don�t like DEMARC because I am worried that ... with mailing lists�. I wonder if we could take a moment to try it and see what happens?
>
> As an example of the case that comes to mind, see attached. It is a message sent to [email-masked] yesterday. The sender signed it using DKIM, the IETF changed the message (added some trailing text) before forwarding it, the receiver (e.g., Cisco IT) attempted to validate the DKIM signature - and failed.
>
> It seems to me that we should not approve a procedure that has that effect, at least without some guidance for mail relay administrators. I could imagine two forms of guidance: �obey the end-to-end principle; don�t change the message the originator sent�, or �if you change a signed message, first validate the message you received and discard if that fails, change it, and then sign it yourself, so that a receiver can see who changed it and validate the outcome�.
>
> Could we actually try such guidance in a sandbox, and document appropriate procedures for mailing lists?
>
>
>
>

---

From: Hector Santos <[email-masked]>
Date: Sat, 03 May 2014 14:08:51 -0400

On 5/3/2014 12:23 PM, Dave Crocker wrote:
> On 5/2/2014 1:05 PM, Fred Baker (fred) wrote:

>       3.  The limitations of DMARC have been well understood, including
> by both Yahoo and AOL.  There is never any way for the IETF community
> to protect against an organization's choosing to apply a protocol in a
> way that is known to have damaging effects.

I find this philosophy quite concerning since the protocol is by 
design, offering strong deterministic policies, options and features 
to select from to both publish and honor -- its part of the protocol 
logic.  Its not there just to "look good" or for show. Its there to be 
used.

Even if only a "small use" case was the purpose, the receivers still 
had to be ready for it.   The problem here is not applying the same 
protocol principles equally and across all would-be compliant domains.

Let me ask, what if a fedex.com employee use this email domain for 
subscribing to the IETF list?  Fedex.com exposes their DKIM signing 
practice very clearly with both an ADSP "dkim=discardable" and a DMARC 
"p=reject" policy.  They wanted to cover a wider net of either 
ADSP/DMARC receivers.   So why would you treat yahoo.com or 
facebook.com "p=reject" policy any different than Fedex.com? 
Facebook.com assigns facebook.com email address now for your account. 
  So its technically possible to use it on a list.

At what point do you adjust to a new DKIM+POLICY layered world?

>       4.  There is, in fact, a draft BCP about DMARC use that was
> posted and awaits pursuit, preferably in the IETF.[1]  Working on it
> got stalled by the gyrations of trying to decide how to process the
> DMARC base specification.  Perhaps we should focus our energies into
> firing up an IETF engine to develop and progress the BCP?

Repeating, highlighting, emphasizing in a BCP not to publish 
restrictive DMARC policies isn't going to solve the problem.

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Sat, 03 May 2014 09:23:10 -0700

On 5/2/2014 1:05 PM, Fred Baker (fred) wrote:
> As an example of the case that comes to mind, see attached. It is a
> message sent to [email-masked] yesterday. The sender signed it
> using DKIM, the IETF changed the message (added some trailing text)
> before forwarding it, the receiver (e.g., Cisco IT) attempted to
> validate the DKIM signature - and failed.
> 
> It seems to me that we should not approve a procedure that has that
> effect, at least without some guidance for mail relay
> administrators. I could imagine two forms of guidance: “obey the
> end-to-end principle; don’t change the message the originator
> sent”, or “if you change a signed message, first validate the
> message you received and discard if that fails, change it, and then
> sign it yourself, so that a receiver can see who changed it and
> validate the outcome”.

Fred,

Your comments are consonant with the recurring comments of others, so
it's worth repeating several fundamental points about them:

     1.  The so-called "end to end principle" was actually labeled end
to end /arguments/.  It is a guidance about a design approach that
then needs to be tailored to the specifics of the situation.  For
example, the definition of 'end' varies according to the scenario.
With direct, person-to-person email the mailbox is an end point. For
EDI over email, it isn't, since there is a further processing sequence
after email delivery.  So we need to be rather careful when asserting
the 'principle'.  In the IETF, we've grown fond of tossing out the
label as if its mere statement is useful.  However it's actual utility
only happens as part of a tailored design discussion.  Like a
protocol, its utility requires being set into motion.

     2.  In terms of basic email architecture, a mailing list is an
end-point.  The author specifies the mailing list explicitly.  The
mail gets /delivered/ to it.  A mailing list is not an MTA that is
relaying mail; it is an end-user application that /re-/posts it.  So a
mailing list is really a value-add mechanism that sits above the basic
email service.  In architectural terms, this is identical to your
choosing to forward this note to someone you think should see it.
DKIM is meant for transit protection, starting somewhere near the
(original) author and ending somewhere near the mailbox of the
specified (initial) recipient.  In the case of a mailing list, that
mailbox belongs to the mailing list.  Should a DKIM signature survive
your manual forwarding of a message?  While it's certainly acceptable
for it to survive, it's not reasonable to expect it.  Then why should
we expect the re-posting by a mailing list to preserve a DKIM
signature? Depending upon the policies of a specific mailing list,
there are many very good reasons for the changes that are made to the
original message.  Some of those happen to break a DKIM signature.

d/

[1] Using DMARC, https://datatracker.ietf.org/doc/draft-crocker-dmarc-bcp/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 May 2014 11:48:56 -0700

On May 2, 2014, at 11:22 AM, Christopher Morrow <[email-masked]> wrote:

> On Fri, May 2, 2014 at 2:05 PM, Fred Baker (fred) <[email-masked]> wrote:
>> We have been having a fairly extended discussion, much of which seems hypothetical - “I don’t like DEMARC because I am worried that ... with mailing lists”. I wonder if we could take a moment to try it and see what happens?
>> 
> dkim != dmarc (but maybe that wasn't your point)
> 
>> It seems to me that we should not approve a procedure that has that effect, at least without some guidance for mail relay administrators. I could imagine two forms of guidance: “obey the end-to-end principle; don’t change the message the originator sent”, or “if you change a signed message, first validate the message you received and discard if that fails, change it, and then sign it yourself, so that a receiver can see who changed it and validate the outcome”.
>> 
> which mailing list software? or did you mean test a general solution
> and document the general solution?

Dear Chris and Fred,

There is a TPA (third-party authorization using hash labels) draft being revised aimed specifically at solving this problem without introducing new demands on mailing-list and other third-party services, or requiring per destination signatures.  The goal is to mitigate disruptions caused by strict policy requests as possible with DMARC while still allowing trusted domains (author domains) a means to effectively delist any authorized source when abuse is detected.  Delisting should only occur after third-party administrators have been allowed to correct the issue.

This approach allows author domains fine grain control over third-party conveyance of initial messages, even over multiple services as can occur with mailing-lists.  It will not increase message size.  It can scale to massive levels having little overhead.  Much less overhead than that required to support SPF or DKIM, the basis of DMARC.

Regards,
Douglas Otis

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 2 May 2014 18:05:37 +0000

Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01
From: Owen DeLong <[email-masked]>
To: joel jaeggli <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>, "Fred Baker (fred)" <[email-masked]>, V6 Ops List <[email-masked]>, "Byrne, Cameron" <[email-masked]>
Date: Thu, 1 May 2014 20:57:57 -0700

> fec0::/10 was reserved way back in rfc 1884
> 
> 3879 and 4193 are contemporaneous activities. meany people on this list
> were present for them.
> 
> The fact that we did a bad job at something 20 years ago doesn't mean
> the problem that we were attempting to address went away.

I agree… People wanting to do NAT rather than learn how to do things better without it is an education problem which continues to persist to this day.

Owen

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 2 May 2014 14:22:24 -0400