Subject: [dmarc-ietf] Updated mandatory tag/conditional signature draft

From: "John Levine" <[email-masked]>
Date: 9 Apr 2015 02:06:37 -0000

I updated my conditional signature draft, which is now (thanks to a
suggestion from Ned Freed) the mandatory tag draft.

https://tools.ietf.org/html/draft-levine-dkim-conditional-01

The idea is that you have a weak signature on To, From, Date,
Message-ID but not subject or body, with a new tag that says the
signature is only valid if it's also signed by a specified other
party, who would be the entity that you expect to forward the message.

So I send a message signed like this:

 From: [email-masked]
 To: [email-masked]
 DKIM-Signature: ...; d=taugh.com; ... ordinary good strong signature
 DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ...  weak signature, not good yet

The list does what it does to the message, and now it's signed like this:

 From: [email-masked]
 To: [email-masked]
 DKIM-Signature: ...; d=taugh.com; ... broken strong signature
 DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ...  weak signature, good because it's also signed by ietf.org
 DKIM-Signature: ...; d=ietf.org; ... new good strong signature

It seems to me that this addresses the same issues that the list
mutation stuff does with a lot less complication, and without having
to enumerate all of the ways that a list might change the message.  It
only assumes that the list won't change To, From, Date, or Message-ID,
which matches my list experience.  The list can make arbitrary changes
to the message body, but if it does, you know who to blame.

As a lazy list operator, I also like the fact that it doesn't require
lists to do anything different from what they should be doing now,
sign their outgoing mail.  Senders put additional weak signatures on
mail sent to addresses that might be mailing lists, verifiers have to
upgrade to understand new signatures.  Note that smelling like a
mailing list is not the same as whitelisting mailing lists.

R's,
John

PS: The spec uses DKIM-Signature v=2 since mandatory tags aren't
backward compatible, but can we please not go down that rathole again,
at least not until we consider whether double signing is useful.

---

From: Hector Santos <[email-masked]>
Date: Wed, 08 Apr 2015 22:56:55 -0400

>   DKIM-Signature: ...; d=ietf.org; ... new good strong signature

Good idea.

The outbound signer will create two signatures; a weak 1st party to 
satisfy the DMARC alignment, and the 2nd signature has a "@fs=" tag 
identifying the PENDING authorized 3rd party signer.

The 3rd party signer will do its natural thing and sign the mail as a 
3rd party signer. However, it MUST KEEP the other signatures. Do not 
remove the previous signatures, in particular the weak 1st party 
signature.

The receiver will now have two signatures:

    - 1st party signature with @fs pointing to the 3rd party signature.
    - 3rd party signature

New DMARC receivers following this idea will check for a two 
signatures requirement in order to pass this test. The 1st party 
authorizes the 3rd party with the @fs= tag.

Old DMARC receivers SHOULD NOT fail because it sees a valid WEAK first 
party signature.  However, depending on the implementation it COULD 
see a 3rd party signature as an violation of the exclusive DKIM 1st 
party only signing requirement.  In other words, there should be no 
"Indirect" indicators in the mail.  Having a 3rd party signature 
MAY/CAN BE leveraged for bad mail, unexpected "indirect" mail filtering.

Across the board, unlike ATPS, this idea has more change requirements 
at signers, receivers and also MLS software to make sure they do not 
strip the weak 1st party signature.

For the signers, like ATPS, there is still a scale problem here for 
the big guys with thousands of list domains.  How will the signing 
machines determine which messages are for list domains?

Overall, its a good idea, but its still a lot of work, more so than 
ATPS requires. This idea requires the signers, receiver and the MLS to 
adapt to new rules. I still think it is easier for the domain to 
publish a 3rd party authorization record and for any receiver to do 
3rd party signature DNS authorization checks w/o 1st party records. 
No overhead and complexity in DKIM signing and receiver machine change 
required.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Apr 2015 21:52:29 -0700

On Wed, Apr 8, 2015 at 7:06 PM, John Levine <[email-masked]> wrote:

> [...]

Well, I'm game to try.  Adjustments to the parsing engine should be fairly
simple, and a couple of extra steps to notice and resolve the forward
reference will be needed.  And maybe some extra return codes.  I'd use "!"
instead of "@", I think, as an indication of their importance when observed
visually, but that's rather a minor point.

The first thing that hits me: Do we have to be specific about what's meant
by "weak"?  How does the verifier decide if it's "weak enough" or perhaps
"too weak"?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2015 08:10:19 -0400

Fairly simple? I'm not sure about that.

1) The signer engine needs to do two signatures now.  This will be a 
major code change, more outbound signing overhead. There is still that 
so called scalability, "big data" problem.  How will the "YAHOOs" 
scale this?  A database is still needed of which domains will have an 
outbound mail stream with two signatures.  Some how the list domains 
will still need to register with the Yahoos and tell the Yahoos, 
"Please send us two signatures authorizing out list domain."    I 
would like to call this a "registration" problem because thats seems 
to be the area of disagreement as a real problem.

2) Two (actually all) receivers now have to comply; the MLM MDA 
receiver (middle ware) and the final User MDA receivers. All middle 
ware MUST NOT strip the weak 1st party signature.

All this is not fairly simple changes. The idea has the same end 
result for 3rd party authorization with more complex calculations at 
all points; signers, middle ware and receivers.   This is far more 
complex than a simple DNS lookup of the ADID/SDID at the receivers 
satisfying the same end result question -- "Does the ADID authorize 
the SDID as a signer?"

Are we trying to skip the DNS part from the solution of all this?   I 
would like to ask the chairs, if the Indirect Mail Interop report 
including further explorations into ATPS and TPA, then why is that not 
happening, and who will do it?   Obviously, Murray is showing his 
disinterest in completing the DKIM ATPS work.

The IETF should present all the solutions in this complicated project. 
Compared to what being proposed with this idea and Murray's other two 
ideas, the DNS lookup method is still a viable option, if only, to be 
included in the total solution pack:

     DKIM+DMARC+ATPS as a faster, optimized, least change approach, 
more proven in the
     market place with APIs already set to do the ADID lookup.

     DKIM+DMARC "In-band" method, such as Levine's @FS= idea for, I 
guess, for
     the customers out there that, for some reason, want a more 
complex DKIM
     engine in signing and verifying in order to do the same thing, 
perhaps
     because they have problems interacting with their DNS administration
     requirements?

Even if this dual signature @FS= approach goes forward, the software 
change requirements will allow for an optimized DNS authorization 
lookup method to be included.

-- 
HLS

On 4/9/2015 12:52 AM, Murray S. Kucherawy wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Apr 2015 05:28:39 -0700

> to the message body, but if it does, you know who to blame.

That last sentence is basically what I said about both of my drafts, and
that logic was shot down.  Once you've decided you don't like the arbitrary
changes, you know who to blame, but you still have to decide what you like
and what you don't.

> mailing list is not the same as whitelisting mailing lists.

"might be mailing lists" sounds like a place for heuristics.  How would you
identify an address that might be a list, or content that's likely destined
for a list?  The "-l" suffix isn't that common these days.

-MSK

---

From: Anne Bennett <[email-masked]>
Date: Thu, 09 Apr 2015 09:24:44 -0400

Hector Santos <[email-masked]> writes:

> A database is still needed of which domains will have an 

I have to agree; if this is the case, to me, it is a
show-stopper.  The genius of the DKIM and SPF and DMARC
approaches is that they are DNS-based, and thus completely
decentralized.  The idea that lists would have to register with
the e-mail providers of all of their contributors, or that I
as a (very small!) e-mail provider would have to figure out
what is and isn't a list, doesn't scale.

I have not yet taken the time to fully understand the "weak and
strong signatures" idea, but if I may be forgiven for commenting
anyway: could the above problem be solved by having "original"
signers always supply various forms of signature (without
needing to figure out if the receiver address is a list), and
having "intermediate" signers (such as mailing lists) add more
signatures as described in the draft?  A message that arrives
with only the "original" signatures would be checked against
the strong one, and a message that arrives with "additional"
signatures would be checked as per the draft.

Of course, if the idea of specifically setting up a third-party
trust is crucial to the proposal, then my suggestion is useless,
and the "registration problem" is not solvable.

Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email-masked]                                    +1 514 848-2424 x2285

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 09 Apr 2015 16:17:18 +0200

> what is and isn't a list, doesn't scale.

This can be solved by having the owners of mailing lists publish a 
yet-to-be-defined DNS record in which they proclaim the presence of a 
mailing list within that domain. I'm contemplating to write a draft for 
this, as more than one of the  suggested solutions to the mailing list 
problem might benefit from this.

Having said that, I don't like the idea of designing all sorts of 
auxilliary technologies to solve the problems introduced by DMARC, or 
better said: if we'd come up with such helper technologies we should try 
to address as many use cases, presented in [1], as possible. If we do 
not, at the the end of the day we'll have created a myriad of new 
technologies, considerably increased the complexity of the e-mail 
ecosystem worldwide with a net result of zero as long as senders still 
treat p=reject as p=none/quarantine.

/rolf

[1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 9 Apr 2015 14:51:37 +0000

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Rolf E.
> Sonneveld
> Sent: Thursday, April 09, 2015 10:17 AM
> To: Anne Bennett; [email-masked]
> Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
> 
> >> A database is still needed of which domains will have an outbound
> >> mail stream with two signatures.  Some how the list domains will
> >> still need to register with the Yahoos and tell the Yahoos,
> > I have to agree; if this is the case, to me, it is a show-stopper.
> > The genius of the DKIM and SPF and DMARC approaches is that they are
> > DNS-based, and thus completely decentralized.  The idea that lists
> > would have to register with the e-mail providers of all of their
> > contributors, or that I as a (very small!) e-mail provider would have
> > to figure out what is and isn't a list, doesn't scale.
> 
> This can be solved by having the owners of mailing lists publish a yet-to-be-
> defined DNS record in which they proclaim the presence of a mailing list
> within that domain. I'm contemplating to write a draft for this, as more than
> one of the  suggested solutions to the mailing list problem might benefit
> from this.
> 

How does this solve anything? What prevents non-owners of mailing lists proclaiming the presence of a mailing list within "that" domain? What prevents malicious individuals setting up a mailing list and proclaiming it?

> Having said that, I don't like the idea of designing all sorts of auxilliary
> technologies to solve the problems introduced by DMARC, or better said: if
> we'd come up with such helper technologies we should try to address as
> many use cases, presented in [1], as possible. If we do not, at the the end of
> the day we'll have created a myriad of new technologies, considerably
> increased the complexity of the e-mail ecosystem worldwide with a net
> result of zero as long as senders still treat p=reject as p=none/quarantine.
> 

You will never avoid "local policy" - that is reality. As an aside, don't you mean " as long as VALIDATORS still treat p=reject as p=none/quarantine."

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 09 Apr 2015 17:29:13 +0200

On 04/09/2015 04:51 PM, MH Michael Hammer (5304) wrote:
> How does this solve anything?

At least it could help in discovering what domains potentially houses a 
mailing list. Whether to trust this assertion is something different. I 
can imagine ESPs could combine this information with information they 
already have about mailing lists (Yahoo once claimed there were only 
30,000 of them, so one way or another they already had some list of 
mailing lists?).

> What prevents non-owners of mailing lists proclaiming the presence of a mailing list within "that" domain? What prevents malicious individuals setting up a mailing list and proclaiming it?

Nothing at all. But the same holds true for registering with the e-mail 
providers. Actually, publishing a DNS record might be seen as a 
submission for registration with the sender. The sending domain still 
determines whether to accept that registration (and use @fs=domain) or not.

> You will never avoid "local policy" - that is reality. As an aside, don't you mean " as long as VALIDATORS still treat p=reject as p=none/quarantine."

Yes, sorry, you're right: that should be 'validators'.

/rolf

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2015 18:25:05 -0000

>changes, you know who to blame, but you still have to decide what you like

Yeah, now that I look at your drafts again, I see that we are both
making the same assertion that this message is a mutated version of
one that someone else sent.  I still like mine better because trying
to enumerate all of the possible kinds of changes doesn't work very
well, e.g., subject tags and per-recipient S/MIME encryption.  (Sympa
can do the latter.)

>for a list?  The "-l" suffix isn't that common these days.

Looking at my DMARC reports from Gmail, the tags suggest they have a
pretty good idea of where the lists are.  It doesn't have to be
perfect, just avoid sending the weak signature to recipients who are
likely to be malicious.

Re other notes, there's no need to define what a "weak" signature is,
since the conditional signature is an ordinary DKIM signature that is
verified in the usual way, give or take the new @fs tag.  It's up
to the original signer how much latitude it wants to give forwarders.

R's,
John

PS:  for @ vs !, I think the bike shed would look great in a dusky
rose with mocha-taupe trim.

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2015 18:27:28 -0000

>> outbound mail stream with two signatures.

Sorry, no, that's completely wrong.  Please reread the draft.

>signatures as described in the draft?

No, the problem is that the intermediate signer has changed the
message in a way that breaks normal signatures.  You wouldn't
want to accept a weak signature on its own, since then any
malicious third party could have rewritten the messsage, not
just the intended recipient.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2015 18:29:24 -0000

>mailing list within that domain.

That's unlikely to work, because malicious people can publish anything
that legitimate lists can.

There's a fundamental rule that anything you publish about yourself
can only decrease other people's opinion of mail that appears to be
from you, not increase it.  DMARC, for example, is all about saying
mail that appears to be from you actually isn't.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2015 14:36:26 -0400

On 4/9/2015 10:17 AM, Rolf E. Sonneveld wrote:
> mailing list within that domain. I'm contemplating to write a draft
> for this, as more than one of the  suggested solutions to the mailing
> list problem might benefit from this.

Its either going to be a internal database or a public database, and 
with internal, we begin to have targeted sites (those without a database).

> better said: if we'd come up with such helper technologies we should
> try to address as many use cases, presented in [1], as possible. If we
> do not, at the the end of the day we'll have created a myriad of new

+1

Following john's example, he wishes for "taugh.com" to authorize 
"ietf.org" as a 3rd party signer.  Using ATPS, he would create a DNS 
record:

    base32(sha1("ietf.com"))._atps.taugh.com

This would be it. The receiver will just check for this ATPS record. 
The only reason for the base32(sha1()) hashed subdomain was because 
there was a domain name length concern or some possible INTL character 
concern, as I recall.  But I am not sure we need it, it would 
certainly remove API complexity when the record is simplified to:

      ietf.org._atps.taugh.com

In any case, this would be it.  The receivers will see:

   From: [email-masked]
   To: [email-masked]
   DKIM-Signature: ...; d=ietf.org; ... new good strong 3rd party 
signature

This provides the two variables for the DMARC+ATPS lookup:

    POLICY = DKIM_DMARC_ATPS(ADID, SDID)

We can't be using a DNS lookup as a reason for not using ATPS and 
continue to investigate these alternatives which have even higher 
overhead.  In DMARC+ATPS, you would have 1 additional DNS lookup. 
With the @FS=1 lookup ideas, you also have 1 additional signature key 
lookup.

I agree that the "database" is the key issue here.  But the above 
Protocol model is the same with a blackbox functionality where we have 
known inputs (ADID, SDID) and known outputs (ACCEPT, REJECT, 
QUARANTINE, DISCARD) we want to have.  There are boundary limits here. 
  All possible input and actions are known, including doing nothing.

PS: This is what we have for our authorized signers under my isdg.net 
zone:

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT	( "v=atps01; 
d=megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT	( "v=atps01; 
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT	( "v=atps01; d=gmail.com;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT	( "v=atps01; d=mipassoc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )
q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT	( "v=atps01; d=isdg.net;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT	( "v=atps01; 
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT	( "v=atps01; 
d=santronics.com;" )

Is it really a DNS concern these days if a textual zone file has 30k 
or 50K subdomain records?  Is it a limit due to their text editor? 
I'm sure a GUI will help, but the text guys are still going to popup 
their editor too.  Is that still a problem today?  I don't think so. 
  New tools can be written to automatic the process.    This should 
not be a DNS or Configuration/Setup limitation issue.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2015 14:49:44 -0400

> Sorry, no, that's completely wrong.  Please reread the draft.

Do you have a reference point, text in the draft related to this to 
clear it up?

How will signers know what domains will have the extra processing, 
dual signature creation enabled?   Does all outbound mail get dual 
signatures?   How will Yahoo know that ietf.org is an "authorized" 3rd 
party signer in order for yahoo to create two signatures?

As you know this will create a major loophole. Your security section 
admits as much to the security loophole.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 09 Apr 2015 11:53:30 -0700

> and the "registration problem" is not solvable.
Dear Anne and Hector,

Tag/conditional DKIM expects ESP now offloading support
issues onto various third-parties to instead apply extremely
limited signatures against all outbound messages while
guessing their user's recipient's signing domain in hopes
this new signature might satisfy DMARC's From alignment
requirement as seen by receivers implementing DMARC.  This
still ignores Sender header fields claiming to have actually
sent the message. 

ESPs would have less overhead and would handle smaller
message sizes by simply ensuring clients see Sender header
fields when used as a basis for acceptance.  In any case
DMARC should be adjusted to assert support for any new
alignment or signature mode of operation.  Outlook already
provides a means to expose the Sender and can be done with
rather simple MUA reconfiguration to select displayed headers.

TPA-Label in comparison represents both a database
established by the DMARC domain to eliminate any additional
message overhead while not imposing changes on third-party
services. 

ATPS remains flawed since it also required special DKIM
signatures by third-party services to somehow also determine
possible DNS label encoding variants employed by a user's
domain.  In essence, ATPS imposes a database support
requirement onto those likely offering a free third-party
service while also expecting similar support from ESPs. 
Tag/conditional DKIM is not really that much better, since
it still depends on support from ESP's and fails to offer a
better fallback mode when these ESPs fail to act.

Regards,
Douglas Otis

---

From: Brandon Long <[email-masked]>
Date: Thu, 9 Apr 2015 13:18:16 -0700

Since you're continuing this push for atps, I should point out again our
issue.  Its not with some editor or serving the large number of records.

Its how do I validate 50k different third parties to say, sure, they can
send with gmail.com.

And it also won't help when someone creates yet another domain and now I
need 50001 records.

Every Google Apps domain has mailing lists (Google Groups) support, should
I put all of them automatically on such a list?  That's way more than 50k
records at that point, and even if they're paying me (Google) money, I
don't know if I would trust them to send from gmail.com or google.com.
Currently, for sending mail as google.com, we require vendor level security
audits... am I supposed to just say "ok" to every random mailing list that
googlers are on?

Brandon

On Thu, Apr 9, 2015 at 11:36 AM, Hector Santos <[email-masked]> wrote:

> Its either going to be a internal database or a public database, and with
> internal, we begin to have targeted sites (those without a database).
>
> Following john's example, he wishes for "taugh.com" to authorize "ietf.org"
> as a 3rd party signer.  Using ATPS, he would create a DNS record:
>
> This would be it. The receiver will just check for this ATPS record. The
> only reason for the base32(sha1()) hashed subdomain was because there was a
> domain name length concern or some possible INTL character concern, as I
> recall.  But I am not sure we need it, it would certainly remove API
> complexity when the record is simplified to:
>
>      ietf.org._atps.taugh.com
>
>   DKIM-Signature: ...; d=ietf.org; ... new good strong 3rd party signature
>
> We can't be using a DNS lookup as a reason for not using ATPS and continue
> to investigate these alternatives which have even higher overhead.  In
> DMARC+ATPS, you would have 1 additional DNS lookup. With the @FS=1 lookup
> ideas, you also have 1 additional signature key lookup.
>
> I agree that the "database" is the key issue here.  But the above Protocol
> model is the same with a blackbox functionality where we have known inputs
> (ADID, SDID) and known outputs (ACCEPT, REJECT, QUARANTINE, DISCARD) we
> want to have.  There are boundary limits here.  All possible input and
> actions are known, including doing nothing.
>
>
> e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT      ( "v=atps01; d=
> megabytecoffee.com;" )
> jchjykxmwknbyfge2bg4td6add264olh._atps TXT      ( "v=atps01; d=
> winserver.com;" )
> rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT      ( "v=atps01; d=
> mapurdy.com.au;" )
> tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT      ( "v=atps01; d=
> santronics.com;" )
>
> Is it really a DNS concern these days if a textual zone file has 30k or
> 50K subdomain records?  Is it a limit due to their text editor? I'm sure a
> GUI will help, but the text guys are still going to popup their editor
> too.  Is that still a problem today?  I don't think so.  New tools can be
> written to automatic the process.    This should not be a DNS or
> Configuration/Setup limitation issue.
>
>
> --
> HLS
>
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Apr 2015 14:36:25 -0700

> well, e.g., subject tags and per-recipient S/MIME encryption.  (Sympa

What we're claiming is slightly different.  Your approach is to trust that
the "fs" domain isn't malicious; mine is to claim responsibility for only
the original content and allow the second domain to claim its
modifications.  I guess it depends on which side we want to mess with more.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 9 Apr 2015 17:46:50 -0400

> modifications.  I guess it depends on which side we want to mess with more.

I suppose that it would be interesting to know what part of the message is 
whose fault to do forensics, it doesn't seem very useful for the pass/fail 
decisions we need from DKIM and DMARC.

We all seem to agree that we're not going to tell people to display DKIM 
signed and unsigned parts of the message in different color, so I doubt 
we're going to tell them to display origin vs. list parts in different 
colors either.  And I like subject tags.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Apr 2015 14:47:26 -0700

> Currently, for sending mail as google.com, we require vendor level
> security audits... am I supposed to just say "ok" to every random mailing
> list that googlers are on?
>

This is precisely why I am "showing my disinterest in completing the DKIM
ATPS work", and also why I don't think things like DSAP or TPA will work
either.  They all amount to creating a registration burden on the author
domain, and those sorts of approaches do not scale.

Solutions to this problem have to be self-contained in order to stand a
chance of being viable.  The drafts before us now attempt to augment DKIM
in a way that doesn't create any extra queries to the DNS or any other
registry to validate.  So far, this seems way more palatable.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2015 18:22:12 -0400

> issue.  Its not with some editor or serving the large number of records.

I'm pushing for the original DKIM+POLICY framework using a DNS Lookup. 
  SSP had 3rd party language, ADSP removed it thus shooting itself it 
the foot. Still a great idea, a "Super ADSP" was released called DMARC 
however, unfortunately, with the same ADSP limitations.  The 
DKIM+POLICY protocol was incomplete. ATPS, TPA was proposed to closed 
that gap.  They are on the table.  I believe ATPS is the best and most 
practically approach we have.  TPA is too complex to achieve the same 
result ATPS provides.  This @FS= dual signature idea is the same 
thing, via more DKIM processing power, needlessly. There is no 
reduction in DNS calls.

> And it also won't help when someone creates yet another domain and now I

I don't see how 50k, or even 100K, 1M or more records would limit you. 
  Are you saying you can't create the tools to manage this?

> I put all of them automatically on such a list?

Perhaps, explore it.  Maybe it will help in the automation.  Also, do 
you really need for this to be instantaneous?  Having all the records 
now to get started?  Can it be gathered over time?  What if we were 
starting brand new?  Would it be a good idea then, learning and 
registering domains as they come?

>That's way more than 50k

Thats a different issue -- Trust.  Thats layer 2, see below.

> audits... am I supposed to just say "ok" to every random mailing list that

Perhaps not.  Again, explore it.  You already are doing the ADID 
Policy Lookup. All you would be doing is adding the SDID to the lookup 
model.   The worst that can happen is a short term, perhaps even long 
term, dearth in published records (NXDOMAIN) and the end result is the 
same - a failed DMARC record policy with negative classification. 
That was the same issue with SPF and also DMARC now.  We have 12 years 
of daily statistics collected 
(http://www.winserver.com/public/antispam) and it took quite a number 
of years before SPF even reached a 6% rejection rate it is today.  The 
DNS overhead is already huge where to scale this properly, receivers 
are dependent on having excellent local or uplink cache.  I'm sure 
Google can the overhead that comes with a DMARC+ATPS framework.

There are two layers to this:

o Layer 1, policy filtering. This removes the bad mail, the unexpected 
mail, deterministically, at the system level. You can quarantine it if 
you like, it doesn't matter. Same idea as long as the end result is 
the same -- the user is protected, the domain reputation is not harm, 
and receiver benefits too from controlling abuse.  This layer 1 leaves 
behind a valid stream of DKIM signed mail preparing it for layer 2.

o Layer 2, trust/reputation vendor services. This was to filter the 
"good mail", the trusted signer.  This was the intention of DKIM STD.

So to answer your question, the trust part can be inherently 
acceptable with the ADID authorizing the SDID via a subdomain DNS 
record or you can query some other Trust/Reputation Vendor service API 
to see if they vouch for the SDID.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2015 18:37:07 -0400

> domain, and those sorts of approaches do not scale.

It is still not convincing.  You are already doing a DMARC lookup. You 
are adding a new parameter to the DNS lookup and only when the ADID != 
SDID condition is met.

The registration is a long term process, just like SPF and now DMARC 
was.

> registry to validate.  So far, this seems way more palatable.

I'm sorry, but its not.  It would be more DKIM changes at the all 
points. It is not necessary to be done. Certainly more processing 
overhead and there are additional DNS calls.  For each new 3rd party 
signature, you got a DNS hit.  You can't avoid the DNS hit.   Adding 
ATPS/TPA to DMARC adds only 1 more DNS call and thats only when the 
ADID != SDID.

And how do you expect the new signer to learn when to create two 
signatures?  Where is that registration coming from?   Google still 
needs to learn 50K domains and also figure out how to automate it for 
Google Apps mailing list support.   Its no different Murray.

At this point, you need both ideas:

    If there is a @FS= record, check it, otherwise if ADID != SDID 
check ATPS.

DKIM signers and verifiers should not be put into a design change and 
cost burden when its not necessary.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 09 Apr 2015 18:23:14 -0700

> audits... am I supposed to just say "ok" to every random mailing list that
Dear Brandon,

It is not who is allowed to "send" using your services, it
is which third-party services are used by your services.  It
makes sense to special case DMARC message handling when
third-party services are known to convey legitimate messages
originating from your services and are doing so without
causing abuse that only the DMARC domain can ascertain.

Apologies to Murray, it is NOT a matter about whether the
scheme scales.  This scheme was used by a small group to
handle queries against a major portion of the worlds MTAs
about a decade ago that audited more than 75% of the world's
MTAs  (millions and not thousands).  Back then the scheme
used Postgres which could import matrix tables and handle
CIDR based queries to avoid SQL.  SQL does not scale.  Every
15 minutes reports were generated in the form of zone files
carried forward by DNS.

Part of this audit included detection of abuse and exclusion
of mailing-lists failing to confirm subscriptions.  We
offered to demonstrate this scheme for a major provider to
prove the TPA-Label approach easily scales without issue. 
ATPS can't.  For example, at that time it was rather
apparent your own MTAs could be differentiated into three
groups of distinctly different levels of abuse.  The
TPA-Label scheme ensures an ability to react whenever abuse
is detected leveraging a scheme offering low latency cached
feedback.

The complexity that has concerned Hector among others was an
attempt to lessen the attack surface and not depend solely
on DKIM.  Perhaps this should have been made simpler to
start.  DMARC (ab)use of non-transactional messaging
destroys the role of the Sender header field which makes it
incompatible with SMTP.  Making specific exceptions based on
known or knowable relationships should not impose
unwarranted risk.  Especially when doing so prevents
disrupting valuable services.

Specialized DKIM signature schemes aimed at preserving just
the From header field are based on guessing the next hop a
message may take is highly problematic.  Mailing-lists share
messages among different groups which means a single value
is not sufficient.  Here again, TPA-Label is able to scale
and react as required, but not specialized DKIM signature
schemes.  Do you really want to impose additional signature
handling and overhead awkwardly attempting to cope with real
world deployment that is never as simple as might be expected.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Apr 2015 22:26:36 -0500

On April 8, 2015 9:06:37 PM CDT, John Levine <[email-masked]> wrote:
>DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ...  weak signature,
>good because it's also signed by ietf.org

I wouldn't go so far as to say I like this, but it's definitely the least bad solution I've seen so far. 

Good:

1. No lists of authorized third parties for either senders or receivers to maintain (if the level of security offered by this system is sufficient, then one could just add the new signature all the time).

2.  No messing with the original DKIM design decision to not make DKIM mime aware.

3.  Simple for middle senders like mailing lists. 

4.  Implementation and specification not very complex.

Bad:

1.  Doesn't help third party originators (which may be a feature).

2.  Enables third parties to send arbitrary content that will pass (yes, this is the point, but it's also a negative to some degree).

The key benefit is that it's only a single third party domain. I think that's reasonable.

Although I haven't considered it deeply, I think DKIM v2 is right so that existing verifiers don't process these signatures. 

I do wonder though if there's a potential replay issue. Once a malicious domain arranges to receive a message with one of these signatures on it, then it can send an arbitrary array of bad things and still pass verification. 

I don't have a good solution. Short signature validity times is the only thing that comes to mind. 

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 10 Apr 2015 14:38:39 +0900

Murray S. Kucherawy writes:

 > "might be mailing lists" sounds like a place for heuristics.  How
 > would you identify an address that might be a list, or content
 > that's likely destined for a list?  The "-l" suffix isn't that
 > common these days.

Mailing lists preemptively return-to-author p=reject domains with the
advice to tell their mailbox provider to implement RFC ####, and then
they'll accept posts from those folks.  How to determine which
destinations are lists is an exercise for the mailbox provider, but I
would suppose the user would be asked to add their posting lists to
their profiles, and/or mailbox providers could add *incoming*
List-Post field contents to the user's profile, and/or we standardize
the ML-Sez-Screw-You DSN so mailbox providers can even parse them out
and resend.[1]

That plus the "paranoid and easy" option of delivering only original
parts per Murray's proposal I think is a good shot at a way forward
for mailing lists.

Footnotes: 
[1]  This strikes me as a good way to create backscatter, so maybe
that's not a great idea.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 10 Apr 2015 14:47:42 +0900

Hector Santos writes:

 > Some how the list domains will still need to register with the
 > Yahoos and tell the Yahoos, "Please send us two signatures
 > authorizing out list domain."  I would like to call this a
 > "registration" problem because thats seems to be the area of
 > disagreement as a real problem.

It's an imaginary problem.  The *posters*, not the mailing lists, will
do the registration.  In fact for lists that provide the RFC 2369
List-Post field, it can be done automatically by the MTA (or in the
case of mailbox providers who provide the MUA, too, the MUA).

 > ware MUST NOT strip the weak 1st party signature.

The Mediators are the screwees in any case, they have a strong
incentive to conform.  It's the sending MTAs that are likely to balk.
IMHO, worth a try.

TPA is still on the table for other 3rd party services (invoicing etc),
because conditional signatures do nothing for them.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 10 Apr 2015 11:32:34 +0200

On 04/10/2015 07:47 AM, Stephen J. Turnbull wrote:
> do the registration.

Oohooh, you mean posters, end users, human beings? And how are they 
supposed to know the address they use is a mailing list?

Let me give you an example: I run a mailing list for parents of 
schoolkids, who maintain a schedule to take care of the kids during 
lunch time (go out with the kids to play football, eat with them etc.). 
They use the list to ask 'who can take my turn, I'm ill' and that sort 
of things. I'm pretty sure 90+ percent of these parents have no idea 
they're sending mail to a mailing list.

Clicking on a spam button is something that can be explained, because 
people hate to receive spam. I doubt clicking on a 'this is a mailing 
list recipient' button is something that can easily be explained to 
people. As list manager I don't know how to explain this to them, as 
they're using all sorts of ESPs including some smaller national ones 
which probably won't have this button. Furthermore, as a list manager I 
set all Yahoo and AOL users to 'read-only' last year. How am I supposed 
to know when they will have marked my mailing list as 'mailing list 
recipient', so I can set them to read+write again?

> In fact for lists that provide the RFC 2369

This may be true for the 10 biggest ESPs of the world, but it won't hold 
for the thousands of smaller ESPs/ISPs or businesses who have medium to 
small IT departments and no specific e-mail expertise.

> incentive to conform.

Even with a strong incentive it will take quite some time before 
all/most of the MLMs will have been upgraded to understand v2.

/rolf

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 11 Apr 2015 01:37:29 +0900

> supposed to know the address they use is a mailing list?

It really doesn't matter at this stage?  Don't let the impossible
dream be the enemy of improvement.  *Some* posters will know.  *Other*
posters will have clueful mailbox providers who will be adding
addresses reaped from the List-Post field in the headers of incoming
messages.  AFAICS, assuming that there's no gaping security hole in
the protocols enabling mass-spamming or mass-phishing, the protocol
can be implemented reasonably rapidly and benefit a lot of users.
Dunno if any of the big guys care, of course (a cynic would say "of
course NOT").

And as a last resort, the mailing list can tell them when it explains
why it isn't accepting their post. ;-)

Or if you as a list owner don't like that, you can use one of several
existing mitigations instead.  Nobody (except *my* subscribers @$%&.com
and @"&#$%!.com :-) need suffer, and some will be better off.

 > Furthermore, as a list manager I set all Yahoo and AOL users to
 > 'read-only' last year. How am I supposed to know when they will
 > have marked my mailing list as 'mailing list recipient', so I can
 > set them to read+write again?

Same way you'll know now.  If "no way", what have your subscribers
lost?

 > small IT departments and no specific e-mail expertise.

So they continue their current mitigations.  Who loses by the
availability of this new mitigation?

 > all/most of the MLMs will have been upgraded to understand v2.

Unfortunately, "&#$%!.com and $%&.com don't follow your rules.  They
implement before having answers to your questions, screwing some of
your subscribers.

Bottom line: your complaint is ahead of its time.  It's just the
normal set of lags in deployment, meaning that some users don't get
the benefits other users do, or don't get them until later.  Tell us
first about users who are *worse off* because of implementing such
protocols (envy experienced by users at slow-to-implement providers
and MLMs doesn't count).  If we don't find any such (which I would
count as a grave but not necessarily fatal defect), *then* we can
start on benefit/cost analysis of whether enough users benefit to
justify the costs.

---

From: "John Levine" <[email-masked]>
Date: 10 Apr 2015 17:08:56 -0000

>I wouldn't go so far as to say I like this, but it's definitely the least bad solution I've

That's how I intended it: This one stinks 47% less than the others!

>1.  Doesn't help third party originators (which may be a feature).

I wouldn't say it's a feature, but third parties are a much harder
problem.  The least bad I can think of for that scenario is some sort
of browser oauth thing that lets the third party log into the user's
account to send the message, which is OK for individual mail an
article but not for the PTA's mailing list.

>2.  Enables third parties to send arbitrary content that will pass (yes, this is the point,
>but it's also a negative to some degree). ...

>I do wonder though if there's a potential replay issue.

I'm hoping that signing the Message-ID will limit the damage there.
Many mail systems combine multiple messages with the same ID even if
they don't have the same contents.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Apr 2015 14:29:32 -0700

> because conditional signatures do nothing for them.

I suggest that TPA or ATPS are way too complicated for third party services
like invoicing, because in that case the relationship between the parties
is solid enough that one could just give the other a signing key and be
done with it.  We can do that today.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 12 Apr 2015 19:34:06 -0400

> article but not for the PTA's mailing list.

Yeah.  I don't think it's possible to allow sending by arbitrary 'authorized' 
third parties without also making it possible to allow sending by anyone.

> >2.  Enables third parties to send arbitrary content that will pass (yes,
> >this is the point, but it's also a negative to some degree). ...
> >

I know Message ID is supposed to be globally unique, I don't think that 
Message ID has historically been viewed as a security property.

I got two copies of this message from you with Message ID Message-ID: 
<[email-masked]>.  One was sent directly to me and one via 
the mailing list.  If I were tracking Message IDs for reuse, one of those 
messages would be considered bad.  

My system doesn't combine them, but if it did, I don't know what content would 
be displayed.

For replay protection, I think the Message ID could work, but I think the list 
would have to change to use its own Message ID associated with its signature.

The need to keep and consult a database of historical Message IDs does add a 
substantial negative in my book.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 13 Apr 2015 12:02:43 +0900

Scott Kitterman writes:

 > Yeah.  I don't think it's possible to allow sending by arbitrary
 > 'authorized' third parties without also making it possible to allow
 > sending by anyone.

I don't know how you'd go about authorizing the third party and
validating the authorization, but AFAICS an authorized sender, with
that address in the Sender field and DMARC-but-with-Sender-Alignment,
does for third parties what DMARC does for first parties in From.
(Cue Douglas Otis pitching draft-otis-tpa-label and Hector Santos
pitching some policy framework with authorization via DNS, but I don't
think that auth-by-DNS scales to humongous mailbox providers.)

 > > >2.  Enables third parties to send arbitrary content that will
 > > >    pass (yes, this is the point, but it's also a negative to
 > > >    some degree). ...

Sure.  So are the ads that some providers post on their webmail
clients, and is allowing first parties to send mail at all.  (I wish
my employer would stop, or at least slow down, for example.)  I really
don't see how unwanted content from *authorized* 3rd parties can be
considered to count against these proposals.  If the recipient doesn't
like it, they revoke the authorization; problem solved.

 > For replay protection, I think the Message ID could work, but I
 > think the list would have to change to use its own Message ID
 > associated with its signature.

You can have your cake and eat it, too.  The list can sign a
Resent-Message-ID (as well as the original if it wants to).

 > The need to keep and consult a database of historical Message IDs
 > does add a substantial negative in my book.

Not if you do it already, and many MUAs already do or have an option
to do it.

Remember, anti-spam measures don't have to be perfect, they just need
to make the mischief unprofitable.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Apr 2015 22:13:04 -0700

> think that auth-by-DNS scales to humongous mailbox providers.)
Dear Stephen,

The TPA-Label scheme can signal new requirements, 
such as John's suggestion for a new browser 
authorization scheme.

With respect to auth-by-DNS, SPF already does this 
for outbound IP addresses.  The reason MAPS was 
acquired was to leverage DNS to reduce processing 
overhead essential for malware scanning.  Back 
then, we were answering queries from about 70% of 
the world's MTAs and were processing about 5 
million logs/sec.  SQL could never handle this 
load on a single server.  Custom routines were 
written in C doing heap or Judy sort before 
transferring to zones.

Our normal deployment supported a free service. 
TPA-Label on the other hand would only need to 
handle a tiny fraction of the mail volume 
requiring a DMARC exception.  Unlike the various 
DKIM signing schemes that attempt to predict the 
needs of the next hop, the TPA-Label scheme can 
separately accommodate all possible sources and 
distribution patterns while giving the DMARC 
domain an opportunity to quickly block abuse as 
determined by DMARC feedback which should address 
concerns related to this category of email.  
Requiring a signing process to guess the needs of 
the next hop will be wrong fairly often and ossify 
email into becoming more fragile and less reliable.

The TPA-Label scheme could also permit incremental 
deployment of the next greatest thing without 
being tied to some potentially prone technique 
while also affording better message processing 
information.  Message-IDs can help establish a 
path a message takes through various third-party 
services, and to identify where problems exist.  
No scheme is able to function when administrators 
fail to communicate, where TPA-Label offers 
actionable and authoritative input.

If the DMARC domain fails to step up, then a 
reasonable fallback could require the display of 
the Sender header offering the needed alignment.

That said, I am also working on plan B.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 13 Apr 2015 16:58:41 +0900

Douglas Otis writes:

 > If the DMARC domain fails to step up, then a reasonable fallback
 > could require the display of the Sender header offering the needed
 > alignment.

I don't understand this.  We already see that most professional
spammers exhibit From alignment on much of their traffic.  Sender
alignment is just as easy to implement, even if we could expect MUAs
to conform to the "required display of Sender field".  Users do not
understand the Sender field as far as I can tell.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Apr 2015 11:21:23 -0700

> understand the Sender field as far as I can tell.

To the extent comprehensible, TPA is meant to allow author A to tell
receiver B that mail that has C in (for example) the List-ID field should
be treated as though it came from A.  However, I concur that it means an
impostor can simply do what the TPA record says and thereby succeed; few of
the properties TPA identifies are authenticated in any way.  It might be
helpful to get alignment working through paths that invalidate SPF or DKIM,
but compared to the fact that it basically advertises how to get a "pass"
in an invisible way, it's more scary to me than not.  Now, if that isn't
the case, then I suggest the document falls short of explaining how this is
not an attack vector.

Also, Doug insists that this is not registration, but I don't know how he
can claim this since it requires a DNS entry for every {A, C} pair that
exists which must then be queried by every B that might receive mail from
C.  Unless I'm not understanding use of the term, that's exactly how I
believe we've been using "registration" lately, and the argument on the
table is that any registration scheme is basically a non-starter for
operators for which the cardinality of AxC is or could be large.

As I've pointed out before, ATPS, DSAP, and all other earlier proposals
that required a registration step have also been non-starters.  I'm not
picking on TPA here; I'm saying this entire family of solutions is probably
not the best use of our time, and I suggest there's empirical evidence to
support that claim.

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 13 Apr 2015 23:22:52 +0200

On 04/13/2015 08:21 PM, Murray S. Kucherawy wrote:
> On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Douglas Otis writes:
>
> receiver B that mail that has C in (for example) the List-ID field 
> should be treated as though it came from A.  However, I concur that it 
> means an impostor can simply do what the TPA record says and thereby 
> succeed; few of the properties TPA identifies are authenticated in any 
> way.  It might be helpful to get alignment working through paths that 
> invalidate SPF or DKIM, but compared to the fact that it basically 
> advertises how to get a "pass" in an invisible way, it's more scary to 
> me than not.  Now, if that isn't the case, then I suggest the document 
> falls short of explaining how this is not an attack vector.
>
> Also, Doug insists that this is not registration, but I don't know how 
> he can claim this since it requires a DNS entry for every {A, C} pair 
> that exists which must then be queried by every B that might receive 
> mail from C.  Unless I'm not understanding use of the term, that's 
> exactly how I believe we've been using "registration" lately, and the 
> argument on the table is that any registration scheme is basically a 
> non-starter for operators for which the cardinality of AxC is or could 
> be large.

But, if this 'registration' does not apply to the 'mandatory tag draft', 
that means that every sender will always add the weak signature + 
'fs=<initial domain>' and a replay attack is reduced to breaking the 
weak signature?

/rolf

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 13 Apr 2015 18:22:05 -0400

>'fs=<initial domain>' and a replay attack is reduced to breaking the 

Yes, but the signature is weak in that it covers less of the content, not in any cryptographic sense. 

Far more concerning to me is that once someone has received a message with a valid 'weak' signature, the only protection against replay is Message ID tracking. Tied with short signature expiration, this may be Okay, but it needs to be explored. 

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 14 Apr 2015 08:20:45 +0900

> 'fs=<initial domain>' and a replay attack is reduced to breaking the 

Definitely not.  Some senders may do that.  I suppose many others will
simply refuse to adopt the standard until it is clearly successful.
Yet others may adopt heuristics to determine which of their users'
correspondents are lists.  Finally others might require registration
of lists by the posters in their domains.

Note that the signature is not "weak" (compared to DKIM) in the
cryptographic sense.  Rather it is weak in the sense that if you can
break the crypto, you can pretend to be authorized to add material.
However, if you can break the weak signature, you can break DKIM *by
definition*, and therefore can pretend to be the author.  So there's
no need that I can see for more paranoia about the cryptography of
"weak" signatures than there is for DKIM in general.

The worry is that an authorized resigner might be suborned -- but
that's true of TPA as well.  I think the advantage of TPA is that it's
very easy for the From domain to revoke the authorization and
"publish" the revocation (simply by un-publishing the authorization).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Apr 2015 17:55:44 -0700

On Apr 13, 2015 2:22 PM, "Rolf E. Sonneveld"
that means that every sender will always add the weak signature +
'fs=<initial domain>' and a replay attack is reduced to breaking the weak
signature?

You can't reuse the weak signature without a proper signature from the fs
domain on the same message. I imagine short expiration times mitigate that
risk.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Apr 2015 18:47:35 -0700

Dear Stephen,

I am writing an I-D expanding on DMARC's disruptive views in
hopes of finding a stable path forward.  As an analogy, the
credit card industry outside the US assumes users will
remember their PIN.  In the US, often protection depends on
sporadically checked signatures.  When less is expected of
users, less protection is afforded.

Email as defined includes the role of Sender.  When Sender
is missing, the Author is assumed to play this role.  There
are ways to ensure the Sender header is displayed when
aligned with SPF or DKIM records.  Blocking valid messages
by ignoring the Sender's role suggests email will not
function as defined. 

Allowing DMARC alignment with Sender header fields along
with the display of Sender content ultimately affords users
greater protection.  Only in the case where a domain just
issues transactional messages will ignoring Sender header
fields then make sense.  Otherwise valid third-party
messages will be placed into spam folders or the Author
identity will be munged in response to Sender header field
limitations imposed by the DMARC domain.

Permitting a clean mode of delivery from a DMARC domain
handling normal mail services should be permitted when
Sender is aligned with SPF or DKIM records.  Only by making
an allowance for Sender header fields for normal email use
can Authors be accurately and clearly conveyed.  Yes, this
expects users to understand they are primarily trusting the
Sender which should be displayed much like the pad-lock on a
website.

TPA-Label can further increase protection by allowing a
DMARC domain a means to signal established third-party
relationships.  This would normally involve a small portion
of the email a DMARC domain might send.  Like SPF or DKIM,
TPA-Label would represent an even smaller overhead. 
Alternative efforts at creating weak signatures will also
require advanced auditing of DMARC feedback and of outbound
logs while not improving overall protections or providing
more comprehensive coverage.

TPA-Label may appear complex, but the added information
reduces possible attack scenarios and better ensures various
identifiers can be used to cull these messages. It is
assumed these identifiers would result from an audit of the
feedback characterizing what recipients should expect.  This
would not be the user telling a DMARC domain anything other
than using the third-party service.  TPA-Label is only used
when an exception is to be used to safely handle third-party
services.  TPA-Label will not increase the message size or
involve additional signatures.

While TPA-Label may involve tens of thousands of domains,
our feedback was processed in much the same manner
approaching hundreds of millions queried by MTAs world wide
without imposition of a fee because of its slight overhead.

Use of TPA-Label offers greater scalability than domain
lists included in draft-kucherawy-dkim-delegate or
draft-levine-dkim-conditional.  Unlike these two schemes,
TPA-Label can impose or permit other options at the
discretion of the DMARC domain.  In this case a valid DKIM
signature would be required before excusing a third-party
domain from being subjected to the DMARC policy imposed by
the From domain. 

This record would permit isp.com after it adds a valid DKIM
signature.  This would provide the same results as would be
obtained by draft-kucherawy-dkim-delegate or
draft-levine-dkim-conditional which must impose their
decision isp.com is okay adding an additional signature. 
The possible number of third-party services approved to then
forward the message is limited by the size of a list
supported within the DKIM signature. 

There is no such limit for TPA-Label.  The argument that a
priori DNS publishing is too cumbersome overlooks the
situation when this represents first use of a third-party
domain where other a priori checks are likely needed as
well.  Once a third-party domain is listed, this offers a
low latency lightweight signal to all of the DMARC domain's
MTAs it okay to sign and send, and for others to then
receive a message modified and resigned by isp.com.  The
receiver will not need to perform additional signature
checks beyond normal confirmations for messages from isp.com
containing the domain example.com looking up the following
DNS record:
_HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._smtp._tpa.example.com.
    IN TXT "v=tpa1; tpa=isp.com; param=d;"

Imposing a specific path that email traverses be defined
prior to the message being sent will ossify SMTP into
becoming a fragile and unreliable process.  A cure worse
than the ailment.  The goal is not to create a Pachinko like
path for email to follow.  The goal is to allow the DMARC
domain a means to quickly mitigate abuse.

Perhaps it should be noted, a common structure of safe
third-party domains could be shared among many different
domains, allowing an organization to specialize in
monitoring and maintaining such a list.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Apr 2015 18:56:32 -0700

> domain on the same message. I imagine short expiration times mitigate that

Dear Murray,

We are currently dealing with Botnets leveraging DMARC to
obtain acceptance or abuse detected weaknesses as previously
mentioned.
Botnets are extremely proficient at deploying new attacks to
leverage detected vulnerabilities.   In this case, this
scheme itself represents its own vulnerability.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 14 Apr 2015 19:58:11 +0900

Scott Kitterman writes:

 > Far more concerning to me is that once someone has received a
 > message with a valid 'weak' signature, the only protection against
 > replay is Message ID tracking.

I don't understand the attack you have in mind.  First, do you mean
the Mediator identified in the fs= tag can replay?  Or a third party?
What is the damage that could be inflicted by this replay?  To whom?

Steve

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Apr 2015 07:39:48 -0400

>What is the damage that could be inflicted by this replay?  To whom?

The 'mediator'.  

Once I am in receipt of a message from you with a signature that is fs=me, then I can send mail on your behalf with any parts of the message not covered by the weak signature having arbitrary changes (including complete replacement).

Keeping in mind that one of the advantages of this approach is not needing to keep a real time list of mediator addresses users in your domain might send to, to make this work at scale, I think the fs= signature has to be put on all messages. The reason I put mediator in quotes above is because it's anyone you send mail to.

The damage is that all it takes is one message from your domain sent to a 'bad' domain and then that domain can generate arbitrary messages that will pass the test.

The to whom is to the sender's brand and the receiver if it makes it through to the inbox. 

The one way to catch this that we've come up with so far is Message ID tracking, since that is signed in the fs= signature (so it can't be replaced).  That's not ideal though. 

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 14 Apr 2015 22:44:39 +0900

Scott Kitterman writes:

 > Keeping in mind that one of the advantages of this approach is not
 > needing to keep a real time list of mediator addresses users in
 > your domain might send to, to make this work at scale, I think the
 > fs= signature has to be put on all messages.

I don't think so.  I think that a conservative approach of keeping the
list in the user profile and doing weak signatures in the MUA will
work for a large proportion of users (Yahoo!, AOL, GMail, Hotmail,
up-to-date SquirrelMail etc installations), plus the hard core of
Emacs users (Gnus will have a zero-day implementation, no doubt) and
mutt users (I know, it's not like Emacs and mutt are a significant
proportion anymore, it's the principle of the thing).  Anybody who's
thinking about putting fs= on all users on all outgoing mail will
probably think twice and just not do it.  Or I kinda hope so.

 > The damage is that all it takes is one message from your domain
 > sent to a 'bad' domain and then that domain can generate arbitrary
 > messages that will pass the test.

OK, I hadn't envisioned the "let's see just how badly we can implement
this protocol" scenario, but yes, it's a real issue.  Note that
Murray's other proposal (MIME-part-by-part signatures) supports a
heuristic to get around this (if you can't find any original parts,
it's spam).  I guess you can come pretty close to arbitrary, though.

Steve

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Apr 2015 10:07:49 -0400

> it's spam).  I guess you can come pretty close to arbitrary, though.

I wasn't attempting to do it purposefully badly.

I'm not aware of any significant DKIM signing done at the MUA level.  I think 
(at least for real DKIM signatures) you have to have the MTA do it to mitigate 
risk of signature breakage to to MTA level transformations.  If the signature 
has to be done at the MUA, then we're back to this only works once MUA 
upgrades are done.  I thought we'd agreed forcing MUA modifications was not a 
post for success.

If I misunderstood the proposal and it requires someone to be keeping a list 
of mailing lists used (either globally or by individual users), then I think 
this is not a good idea at all.  I don't think any tracking/whitelisting 
design is going to succeed at scale.

My view is that either we find a reasonable way to make this idea work without 
a list of mailing lists or we toss it on the pile of things that won't work.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 14 Apr 2015 23:56:20 +0900

> I wasn't attempting to do it purposefully badly.

I didn't mean you were *trying* to do it badly.  However, using fs= for
*all* addressees on *all* outgoing mail seems like the worst possible
scenario.

 > I'm not aware of any significant DKIM signing done at the MUA
 > level.  I think (at least for real DKIM signatures)

Exactly.  But the "Big 4" MUAs are in close cooperation (FSVO "close")
with the "Big 4" MTAs.  They could do it in the MUA, or they could
invent a simple protocol to ask their MTAs to do it for the MUA.

 > you have to have the MTA do it to mitigate risk of signature
 > breakage to to MTA level transformations.  If the signature has to
 > be done at the MUA,

No, it doesn't *have* to be done at the MUA.  I'm saying it *could* be
done at the MUA, and with the exception of MTAs that rewrite
Message-ID, I would think the risk for weak signatures is fairly
minimal.  (I know, I know, "famous last words".)

 > then we're back to this only works once MUA upgrades are done.  I
 > thought we'd agreed forcing MUA modifications was not a post for
 > success.
 > 
 > If I misunderstood the proposal and it requires someone to be
 > keeping a list of mailing lists used (either globally or by
 > individual users), then I think this is not a good idea at all.  I
 > don't think any tracking/whitelisting design is going to succeed at
 > scale.

I can't speak for Murray, but I can't see that his proposal does.

My (informal) proposal is a way for the "Big 4" to get into this
without a huge risk of replayable messages going to spammers on a
large scale.

 > My view is that either we find a reasonable way to make this idea
 > work without a list of mailing lists or we toss it on the pile of
 > things that won't work.

Unfortunately, we already have something that doesn't work, it is
deployed at scale, and it continues to cause annoyance at scale (the
guy next to me at the PyCon sprints just got a messaged rejected
because he replied to a ".dmarc.invalid" address).

Really, isn't the question whether Yahoo! and AOL are willing to do
*anything* to mitigate?  We need some participation from them or it's
useless, and if at least one does participate, it's a win.  What are
they willing to think about implementing?

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 11:11:00 -0400

On 4/14/2015 10:07 AM, Scott Kitterman wrote:>
> a list of mailing lists or we toss it on the pile of things that won't work.

Which is why the simple DNS lookup remains to be the ideal baseline 
and natural part of the generic DSAP (DKIM Signature Authorization 
Protocol) design. You need to cover all process model boundary 
conditions which include 1st and 3rd party mail streams. If you 
exclude one, its incomplete.

The Publishing and "Registration" problem has been overblown. 
Registration basically means to find the domains (your network of 
signers) to publish.   The latter is a business problem, not a IETF 
technical protocol problem.  If we had used a "registration/scale 
problem" philosophy for other early IETF protocols, they were have 
never been completed as well and gotten to where we are at now.   SPF 
has this same scale concern, and it still currently an extremely high 
wasteful DNS calling authorization check method for senders.  The 
larger domains also had to "find" their network to register them as 
SPF machines.  So this is not any different.

The DNS "Lookup" algorithm has been the basic backbone idea since 
2003, since LMAP ideas, since DNSRBL, since MAPS, well since forever, 
etc, the idea of "Looking up" an verified, integrity authenticated id 
for authorization, either its for bad or good, it became fashionable 
and an acceptable concept overtime by the DNS community. They bemoaned 
it but the DNS TXT-BASED applications was on the raise as an fast 
entry method to explore many new authorization ideas.

We tried to get the "Good Signer" (SDID) lookup with the DKIM STD 
work. It didn't happen in the
market place (it has issues that included the "Batteries Required" 
syndrome) and even if it did happen, the "Good Signer" methodology did 
not cover rudimentary DKIM signing failures checks (including missing).

In all cases, you need a 3rd party Authorization list somewhere, 
whether everyone needs one or not, some will, some won't.  That again 
is also a implementation and business decision.  You can,  in theory, 
have a more relaxed Signer Engine that double signs all mail or maybe 
under some rule that allows only outgoing LIST domains to be double 
signed.   In all cases, this in-band method is still a registration 
concept, global or selective.

The problem has been that some believe everyone will have this a huge 
need to "register" many domains, and IMV, this erroneous idea has 
crippled the completion of all DSAP protocols  (SSP, ADSP, DMARC). 
No, only a few have such "registration" issues, whether thats a 
million or so, it still a small piece of the total domain space. We 
won't know how many for sure, but I have a pretty good feel the 
majority of domains will not need such large "list" needs.

How many will you have to collect?   I have 10.

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT	( "v=atps01; 
d=megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT	( "v=atps01; 
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT	( "v=atps01; d=gmail.com;" )
LYKM653KJ7YXEIA665VA7LSZZTHCX7JJ._atps TXT	( "v=atps01; 
d=beta.winserver.com;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT	( "v=atps01; d=mipassoc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )
q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT	( "v=atps01; d=isdg.net;" )
ni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT	( "v=atps01; 
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT	( "v=atps01; 
d=santronics.com;" )

Are we saying that MOST systems will not be able to handle their 
Network of known signers?

As stated above, this issue is no different than with SPF where larger 
networks had to learn their network of senders and even then, many 
still use weak/relaxed policies (~ALL, ?ALL) lowering the payoff of 
the redundant calls with no actionable results, indeterminate 
conditions - a high waste most of the time.

The MLM or the site mail receivers just needs to make sure it does a 
ADID/SDID check.  If the WG wants to spend time on a weaker more 
complex double signature "in-band" solution because the DNS 
administrator is no longer needed,  that still doesn't mean that this 
design will be acceptable to all.   The weaker alternative is more 
code change and if you can avoid code change, the better.  DMARC 
SHOULD offer the more ideal and simple DNS lookup because it is a 
natural part of the DNS lookup model that already exist for DMARC 
which currently isolates itself to the ADID==SDID conditions and 
automatically failures all other conditions.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Apr 2015 11:25:15 -0400

> *all* addressees on *all* outgoing mail seems like the worst possible

I think it's the only one that scales, so worst or not, I think it's what you 
get.

> minimal.  (I know, I know, "famous last words".)

8 bit to 7 bit transformations are also not rare.

> I can't speak for Murray, but I can't see that his proposal does.

I haven't reviewed his in detail, so I've no opinion.  I was talking about 
this proposal.  Not getting fancy with MIME parts would be nice, so if this 
one can work, I already like it better than Murray's, but if we have to pile 
this onto the stack of nice ideas, then that's probably what I'll look at 
next.

> without a huge risk of replayable messages going to spammers on a

Which one is that?

> they willing to think about implementing?

Depends on who needs to change to mitigate things.  If (as an example only) we 
decide that From rewriting is the best (least bad) solution, then that's a 
mediator change.  We don't need Yahoo and AOL except to the extent they 
operate as mediators also, but AFAIK, that's different groups at Yahoo and AOL.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Apr 2015 11:30:24 -0400

On Tuesday, April 14, 2015 11:11:00 AM Hector Santos wrote:
> > If I misunderstood the proposal and it requires someone to be keeping a
> > list of mailing lists used (either globally or by individual users), then
> > I think this is not a good idea at all.  I don't think any
> > tracking/whitelisting design is going to succeed at scale.
> > 
> > My view is that either we find a reasonable way to make this idea work
> > without a list of mailing lists or we toss it on the pile of things that
> > won't work.

There's a big difference between needing to know the outbound architecture of 
your own sending (as is needed by SPF and DMARC) and needing to know which of 
all the places you send mail are mediators.

You seem to think keeping a list of mediators like mailing lists is feasible 
and offer a way to do it.  I don't have an opinion on how good the method is 
because I don't there is no way keeping a list can be done regardless of how 
you store it.

Also, for large providers like (for example) Google Groups, you wouldn't want 
to authorize them at the domain level since it's a mix of high quality wanted 
groups and spam groups.  You'd have to do it at the individual mail box level 
to make it workable.  This only amplifies my concern about scalability.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 15 Apr 2015 01:04:34 +0900

> 8 bit to 7 bit transformations are also not rare.

In the header?  I guess with RFC 6532 that could happen frequently
(but those folks are likely to be in trouble with DKIM anyway for the
foreseeable future).

 > Depends on who needs to change to mitigate things.

To implement any of the "weak signature" variants (see subject), the
>From domain has to be involved as sender.  That's why I'm asking.

 > If (as an example only) we decide that From rewriting is the best
 > (least bad) solution,

That's not what this thread is about, and it obviously doesn't need
participation from them.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Apr 2015 12:07:09 -0400

> (but those folks are likely to be in trouble with DKIM anyway for the

Yeah, I forgot what parts of the message we were talking about.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Apr 2015 09:53:01 -0700

> to make it workable.  This only amplifies my concern about scalability.
Dear Scott and Hector,

DMARC offers feedback to help identify where a listing is
needed.  This list can be placed in DNS using hash labels
and TSIG, for example.  There should only be one hash label
function.  Essentially, all the various schemes require
mediators be identifiable.  If it turns out a mediator is a
source of abuse, it should already be in the incoming block
list. Likely another DNS entry.  Since your users will be
unable to see a response anyway don't let users send to
known abusers.  DMARC can signal use of a mediator and flag
this scheme rather than changing or adding DKIM signatures.
No matter the scheme, they all require some form of vetting.
A role that can be played by a repaired ATPS or TPA-Label.

Since mailing-lists are likely to receive special handling
It might be assumed that those allowed to post have been
limited by subscription.  Since a mediator may share a
domain having other uses, TPA-Label is able to differentiate
them to close a subscription gap. Any scheme to enable a
third-party must be very concerned about restricting
access.  How would you envision access be restricted with
draft-kucherawy-dkim-delegate or
draft-levine-dkim-conditional?  In many cases, the From is
already being munged.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 12:59:51 -0400

> all the places you send mail are mediators.

Sure, but first, from a protocol standpoint, it doesn't/shouldn't 
matter, its the same.  Either the ADID publishes the information or 
not.  Second, not every list/email application is the same, so yes, 
some will know and some will not.  Many SPF larger domains do not know 
their outbound MTA, so they include many INCLUDE statements and many 
still have a relaxed policy.   Its not causing a reject but it is 
waste in DNS traffic.

We can't use a "scale" argument here when you have a already high 
wasteful scale issue with SPF.  Just look at google.com.  How many 
includes and its all for a softfail?  Talk about waste. Yet, at times, 
I suppose most of the time, it works, with a PASS result to skip the 
remaining test.

> because I don't there is no way keeping a list can be done regardless of how

Its not that I believe its feasible, but that not unfeasible as well. 
  Its all doable.  We did it. The protocol is the same whether a 
particular site believes it can use it or not.    For our signer 
engine, I can see it doing a @FS=SDID signature because for MLS, it 
makes the mail with a meta header "SIGN-THIS" telling the outbound 
signing engine a specific set of signing rules, i.e. like use l=0, 
don't hash bind the subject line, IOW, make the stream weaker.   So it 
could be done for our product, but its code change and its weaker too. 
    The receiver still needs to do more work.  So think of the 
"Scaling" at all ends.  For non-compliant (@FS=) receivers,  we just 
double their verification work load, an extra DNS Key lookup, all for 
nothing.  At scale, is that a problem?

> to make it workable.  This only amplifies my concern about scalability.

We need to differentiate what we need by "scale" and everyone is 
different. For one of many examples, you are presuming a need for 
Google Groups. I don't need it, nor expect it and there will be 
millions of private operations domains who don't care for it either.

In other words, lets not use marketing decisions to put up barriers to 
the general IETF technical protocol requirement to include the 
authorization for the ADID != SDID condition.  Google is just one 
company and is it causing very very high waste with its soft SPF policy.
This high scale, redundant waste didn't stop most people from using 
SPF. One day, Google will change it to -ALL perhaps.   On the other 
hand for other companies, Yes, I believe it is very feasible and 
manageable.

-- 
HLS

---

From: Terry Zink <[email-masked]>
Date: Tue, 14 Apr 2015 17:12:21 +0000

> On the other hand for other companies, Yes, I believe it is very feasible and 
> manageable.

So, maybe I'm missing something here on the idea of TPA and registration of mailing lists (in DNS), and mentioning Google Groups and how they can figure it out... but not every emailer controls the DNS of the domains they relay email from. Google certainly owns gmail.com, and Microsoft owns outlook.com and Hotmail.com, and Yahoo own yahoo.com, so conceivably they could authorize and auto-publish something.

But there's no way Google Apps and Microsoft's Office 365 (for example) can publish DNS entries for all of its small, medium, and large businesses that use its service and subscribe to mailing lists, because many times those companies don't control the DNS for their customers. They'd (we'd) have to get customers to update their DNS entries for every mailing list they use if we don't have access to their DNS. Getting customers to update their DNS is almost as pleasant as getting my teeth cleaned.

That's what we mean when we say it doesn't scale.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Tuesday, April 14, 2015 10:00 AM
To: [email-masked]
Subject: [dmarc-ietf] Publishing and Registration Concerns

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 13:25:33 -0400

On 4/14/2015 12:53 PM, Douglas Otis wrote:
> and TSIG, for example.

Sure Doug, yes, there are ways to automate this.  The feedback is there
and scripts can be written.

> draft-levine-dkim-conditional?  In many cases, the From is

Too complicated.

One assertion needs to be tested:

     Does the ADID authorize the SDID?

You can query the ADID DNS database for this.  How that data gets 
there is a whole different issue.  In the mean time, the WG should 
work on the DMARC protocol making it ready for a 3rd party 
authorization method.   Doug, TPA is too complicated. I am not 
convince it does anything more than what a simpler ATPS will offer or 
a basic Yes/No Query of the ADID/SDID.  TPA is essentially the same 
lookup method but you tied extra meaning. I don't think its necessary. 
Nonetheless, lets propose a new "sam=" tag in DMARC, "Signature 
Authorization Method"

    v=DMARC1;  sam=tpa|atps|fs

This allows for the intelligent receiver to explore and learn which is 
the best method.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Apr 2015 10:47:20 -0700

On Tue, Apr 14, 2015 at 10:12 AM, Terry Zink <[email-masked]>
wrote:

> But there's no way Google Apps and Microsoft's Office 365 (for example)
> can publish DNS entries for all of its small, medium, and large businesses
> that use its service and subscribe to mailing lists, because many times
> those companies don't control the DNS for their customers. They'd (we'd)
> have to get customers to update their DNS entries for every mailing list
> they use if we don't have access to their DNS. Getting customers to update
> their DNS is almost as pleasant as getting my teeth cleaned.
>

...and remove entries when one of them stops using a mailing list.  And for
all we know this might happen with such scale that it begins to affect DNS
caching of other useful data.

> That's what we mean when we say it doesn't scale.

Right.  And since the largest problem is with the largest operators
(because they have the biggest impact), a solution they aren't likely to
adopt is probably a waste of precious working group resources.

It's not "marketing" to decide to abandon a protocol that nobody will
actually use.  Rather, it's a highly pragmatic engineering (and working
group) decision.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Apr 2015 11:09:34 -0700

> That's what we mean when we say it doesn't scale.
Dear Terry,

TPA-Label operates within its own sub-domain.  This
sub-domain can be delegated or use DNAME.  This means this
information can be handled by an organization dedicated to
detecting and preventing third-party abuse.  In essence, a
role likely to entail sending notices to domains and
ensuring problems are corrected or having their third-party
provisions retracted.  A function that Yahoo and AOL dumped
on everyone else by (ab)using DMARC.

How is the scaling issue really worse than the changes
currently required for SPF?  In fact, SPF often entails more
DNS transactions per use.  Initially I argued for APL RR
rather than TXT.  People were impatient and wanted something
quickly kludged into every registrar system.  This
impatience resulted in a sizable overhead with many unused
active macro script and policy features due to high error
rates and why DMARC uses the logical OR of DKIM and SPF.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 14:10:38 -0400

On 4/14/2015 1:47 PM, Murray S. Kucherawy wrote:

> actually use.

Why do you keep repeating this when you know it is not true?   We used 
it in real commercial products and it works as designed. It has scaled 
for us.

>Rather, it's a highly pragmatic engineering (and working
> group) decision.

No, If it that was done, it would be a different story.  It wasn't 
done. ADSP was bitterly abandoned and left for dead, you had a major 
conflict of interest with a reputation/trust modeling framework and 
vendors in the market place, therefore any add-on (TPA, ATPS) for it 
would not get serious traction at all. I always felt it will 
eventually, hence adding the support or the basic DKIM+POLICY into the 
framework.

You got a different situation with DMARC replacing ADSP.

It is a making a marketing decision when you exclude a perfectly 
logical, technical and natural part of a protocol out because A) you 
believe it impugns on resigner operations and B) make instantiated 
statements that won't scale.  That SHOULD NOT be your position within 
the IETF to stop it from happening. You should support it because it 
is technically sound.  Don't use it yourself but promote not to use it 
in others in a search for an alternative that is more complex, more 
insecure and more changes and doesn't resolve the so called 
"registration" problem,.

Using parato's principle, it will scale for most of the domains 
because most domains are not Microsoft, Google, Aol or Yahoo.   There 
are more small domains than these relatively few handful.   Using 
parato's principle, most will not have a need to register thousands of 
list domains and using parato's principle, most can handle even larger 
big-data problems just fine.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Apr 2015 11:49:51 -0700

> I can't speak for Murray, but I can't see that his proposal does.

Sorry, I've lost context.  I assume you're talking about dkim-list-canon.

You could apply it only when you know the mail is going to a list, maybe if
you're worried about overall header size or crypto cost, but it's designed
to be used generally.  Since it's a signature that covers the whole
message, it's not replayable (any more than basic DKIM is).

> they willing to think about implementing?

At least one of them is subscribed, but I've no idea if they're actively
monitoring.  At the same time, I think the feedback we're getting from MS
and Google is equally valuable, and they're active.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Apr 2015 11:58:53 -0700

>> That's what we mean when we say it doesn't scale.

I have a fair amount of experience with this approach, since
we published more than 1 billion resource records having 300
second TTLs without issue.  DNS scales as will the scheme
being proposed.  Often these zones are limited to queries
from MTAs given their own resolvers.  What is being
currently described represents orders of magnitude smaller
deployments.  It represents work that everyone wants to
avoid.  Clearly they don't care about third-party services
and don't think email should have ever accommodated the role
of Sender.
> actually use.  Rather, it's a highly pragmatic engineering (and working
The problem we currently have today was born out of
pragmatic reactions by the largest providers.  Lets not
waste time on measures unable to safely repair the damage,
even when it means the community as a group must now carry
the burden forced upon them.  I don't think anyone has
seriously considered the complexity related to publishing
easily exploited DKIM signatures as if malefactors won't
exploit such quick fixes published on mailing-lists.  In the
meantime, I'll soon post another alternative for dealing
with DMARC.

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Tue, 14 Apr 2015 19:03:35 +0000

Hi, Doug,

> sub-domain can be delegated or use DNAME.  
> DNS transactions per use

When I talk about scale [1], it's not just a matter of doing DNS lookups. That's important, but it's not what I worry about because we can solve it by adding more hardware [2]. Instead, by "scale" I mean "management", that is, having humans manage the process, or needing humans to do something.

Getting someone to add anything to DNS doesn't work well [3] unless it is automated because the majority of people that I work with in the customer space don't feel comfortable managing DNS; it is rare that I encounter someone who does and these are people who are in charge of email infrastructure. This is the exact opposite of most people on this discussion list, many of which manage their own zones. For many large organizations, there is a slow change-review process. For medium and small businesses, they just want it to work and therefore don't change much in their DNS unless they are experts, of which there aren't that many in real life.

So to say "Oh, just set up a new DNS record and it will all work" is a major obstacle to overcome and is close to a non-starter. I like the idea of the DKIM/FS from John Levine because at least that can be done at the MTA level without any help from domain owners because it's the job of the MTA implementer to figure it out; it's a much smaller set of people who need to understand and can it make it work without domain owner awareness.

-- Terry

[1] I can't speak for everyone within Microsoft, or anyone within Google or Yahoo but I would imagine they have the same issues because they're both large companies.

[2] That's my solution for everything. It's a simplified explanation, but a good technical design and adding adequate hardware solves most of those problems... usually.

[3] By "work well" I mean have the majority of people doing it, not that it works technically.

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 15:13:36 -0400

On 4/14/2015 2:09 PM, Douglas Otis wrote:

> DNS transactions per use.

It sure does have a much higher overhead. Just take a look at hotmail.com:

        "v=spf1
    1    include:spf-a.outlook.com
    2    include:spf-b.outlook.com
         ip4:157.55.9.128/25
    3    include:spf.protection.outlook.com
    4    include:spf-a.hotmail.com
    5    include:_spf-ssg-b.microsoft.com
    6    include:_spf-ssg-c.microsoft.com
        ~all"

Six DNS calls at the top level and its final result is a relaxed ~all 
result.  That is a super high scale/volume waste of processing.   But 
here again is a large company not getting its list of senders 
completed.  Doesn't stop SPF.

And with DMARC, hotmail.com has no record, so all receivers will be 
doing high volume wasting calls.

We should not expect anything different for a domain finding its 
network of signers.   If it doesn't know its list of signers, then it 
just registered what it can and create a relaxed DMARC policy.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Apr 2015 12:15:16 -0700

> this onto the stack of nice ideas, then that's probably what I'll look at

The elegance of John's idea is that it's content-agnostic, and is
apparently backward compatible because v=1 verifiers will not consider the
weak signature to be valid (unless they're already quite broken).  There's
no need to learn to parse MIME structure in order to produce a signature.

I think the concerning part is deciding when to add the weak signature.
The simplest thing is to always add it along with an "@fs=" signature, but
then you're basically allowing the forwarding domain to sign any content it
wants and you'll be approving it too, implicitly.  If you want to be
selective about when you add it, you have to apply some kind of heuristic
to make that decision.  We obviously can't specify that, but it becomes a
burden to signers.  It's also prone to replays.  It might be enough to use
a short expiration time, but that relies on everyone processing "x="
properly (or at all), and you need to make a good guess as to what
expiration time to use.

Of all the proposals before us, this would be the easiest for me to adopt
and try, followed by dkim-delegate.  dkim-list-canon and dkim-transform
would be the hardest, not only because they will require more code, but I'm
nervous about how sensitive they are to misinterpretations or abuses of
MIME.  For example, I've no idea what would happen to messages with MIME
preambles.  Still, there's something attractive about being able to tell
what the original message was and what the added/modified content was, and
determining who was responsible for what.

Depends on who needs to change to mitigate things.  If (as an example only)
> we

I don't think we need to be worried about their participation.  Unless they
plan to embarrass me later for saying so, they are indeed paying attention,
and will participate in trying something that seems viable.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Apr 2015 12:23:23 -0700

On Tue, Apr 14, 2015 at 12:03 PM, Terry Zink <[email-masked]>
wrote:

> Getting someone to add anything to DNS doesn't work well [3] unless it is
> automated because the majority of people that I work with in the customer
> space don't feel comfortable managing DNS; it is rare that I encounter
> someone who does and these are people who are in charge of email
> infrastructure. This is the exact opposite of most people on this
> discussion list, many of which manage their own zones. For many large
> organizations, there is a slow change-review process. For medium and small
> businesses, they just want it to work and therefore don't change much in
> their DNS unless they are experts, of which there aren't that many in real
> life.
>

Just to pile on: There are probably security people many large
organizations who would be unthrilled with the notion of automating an
authorization process, which is really what this is.  It might feel to them
a lot like an injection attack, and I would argue they're correct.

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 14 Apr 2015 22:24:15 +0200

On 04/14/2015 09:15 PM, Murray S. Kucherawy wrote:
> On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> apparently backward compatible because v=1 verifiers will not consider 
> the weak signature to be valid (unless they're already quite broken). 
> There's no need to learn to parse MIME structure in order to produce a 
> signature.
>
> I think the concerning part is deciding when to add the weak 
> signature.  The simplest thing is to always add it along with an 
> "@fs=" signature, but then you're basically allowing the forwarding 
> domain to sign any content it wants and you'll be approving it too, 
> implicitly.

Remembering to what great lengths the ietf-dkim group went to make sure 
that every bit of a message was covered by the signature (and with the 
l= discussions in mind) I would really be surprised if adding the @fs= 
for all outbound mail would be an acceptable solution for the problem.

/rolf

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 14 Apr 2015 20:55:08 +0000

I've been following the thread(s) regarding how to enable 3rd parties where a formal relationship doesn't exist and this reinforces my thought that it is ultimately easier systemically (even allowing for the arguments that it is unfair) for intermediaries to take ownership of messages they (intentionally) modify and sign d= as first party signers.

I understand that there is a one-time cost (my own organization incurred this cost in changing how we handle mail for our website domains) to changing and I understand the reasons expressed by some for not wanting to make such changes based on principle, etc. I understand the argument that some are externalizing their costs.

Mike

From: dmarc [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
Sent: Tuesday, April 14, 2015 4:24 PM
To: Murray S. Kucherawy; Scott Kitterman
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman <[email-masked]<mailto:[email-masked]>> wrote:

The elegance of John's idea is that it's content-agnostic, and is apparently backward compatible because v=1 verifiers will not consider the weak signature to be valid (unless they're already quite broken).  There's no need to learn to parse MIME structure in order to produce a signature.
I think the concerning part is deciding when to add the weak signature.  The simplest thing is to always add it along with an "@fs=" signature, but then you're basically allowing the forwarding domain to sign any content it wants and you'll be approving it too, implicitly.

Remembering to what great lengths the ietf-dkim group went to make sure that every bit of a message was covered by the signature (and with the l= discussions in mind) I would really be surprised if adding the @fs= for all outbound mail would be an acceptable solution for the problem.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Apr 2015 14:31:11 -0700

On Tue, Apr 14, 2015 at 1:24 PM, Rolf E. Sonneveld <
[email-masked]> wrote:

> that every bit of a message was covered by the signature (and with the l=
> discussions in mind) I would really be surprised if adding the @fs= for all
> outbound mail would be an acceptable solution for the problem.
>

I agree in general, but I'm not sure that's a valid comparison.  A bare
"l=0" is a lot less restricted than one that also includes "@fs=" and,
perhaps, something like a short expiration.  It could well be that's a
tolerable risk when compared with the cost of doing nothing here.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Apr 2015 17:43:15 -0400

>just registered what it can and create a relaxed DMARC policy.

Which is completely orthogonal to the question. Scale for this is about scaling the data collection and DNS record publishing. 

My essentially one person domain would have a more complex forwarder/mailing list list than the SPF records of even the largest providers. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 17:47:36 -0400

> When I talk about scale [1], it's not just a matter of doing DNS lookups. That's important, but it's not what I worry about because we can solve it by adding more hardware [2]. Instead, by "scale"…

But thats the same problem for everything.  How will MS work it out 
for your hotmail.com SPF operations? For SPF, hotmail.com has a 
relaxed SPF policy with a long list of DNS lookups.  Lots of 
processing waste here. For DMARC, thousands, perhaps millions, high 
volume of mail are getting NXDOMAIN on the expectation there is a 
DMARC record.

Are we at a point where all DNS TXT-based solutions will need to be 
converted to in-band mail only solutions and we eliminate DNS from the 
picture?

   if ADID == SDID
      DO DNS_DMARC
   else
      DNS PROBLEM TOO HARD.

Is that what we going to tell the DNS folks on last call?  The better 
solution was punted because interfacing with DNS people is a tough 
problem.

That is what is astonishing me the most here. Billion dollar 
corporations saying this problem is too hard for them to address. 
Wow. I'm sorry, but it seems odd that we were going for a far more 
complex workaround that has security holes just because the we can't 
get the DNS folks involved as part of the solution package when DNS is 
required in the first place.  This all seems very strange to me to 
read this.

I don't mind an In-band solution as an OPTIONAL alternative to the 
more optimized, more secured, more technically feasible, time tested 
simple DNS lookup solution.   The IETF, this WG, the chairs owes it to 
the interested industry participants to offer and provide a solid 
solution, even if it involves getting DNS administration involved.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 17:58:42 -0400

> tolerable risk when compared with the cost of doing nothing here.

That "cost" has already been long established. The simple DNS Lookup 
is cheaper to implement and more secured than the in-band alternative.

All we are learning from this thread is that getting DNS involved is a 
tough problem.  We already knew that for years, since day one of all 
these DNS TXT-based solutions. But how are you going to explain that 
the best and simplest solution for DMARC, the simple ADID/SDID, is 
being blocked because it is presumed that implementators will not be 
able to work with their DNS peers?

Why can't both solutions be done?  The optimized ADID/SDID DNS check 
and the fallback to a @fs=SDID signature check?

-- 
HLS

---

From: Terry Zink <[email-masked]>
Date: Tue, 14 Apr 2015 22:41:29 +0000

>> When I talk about scale [1], it's not just a matter of doing DNS lookups. 
>> That's important, but it's not what I worry about because we can solve 
>> it by adding more hardware [2]. Instead, by "scale" I mean "management",
>> that is, having humans manage the process, or needing humans to do something.

> volume of mail are getting NXDOMAIN on the expectation there is a 

Hi, Hector, sorry to derail your point, but I don't understand your point as it relates to what I was saying. At Microsoft, there's a dedicated team (handful of people) who manage the SPF record and there's a change review process, and expertise moves out of the team gradually. Still, there are people that are assigned to it. In addition, Hotmail.com fits into the 10 DNS lookup limit as required by the RFC.

My point was that Hotmail can inventory what all of its IPs are, and updates its DNS records manually. But plenty of others don't know what their IPs are; furthermore, Office 365 does email hosting for small, medium, and large businesses. The part that doesn't scale is the following:

1. For Hotmail, every mailing list that our users are signed up for would result in a new DNS entry. How do we manage the lifecycle around that? Should we automate its addition? Should we automate its removal? Do we delay email before the DNS entries are published? Should we thereby bypass the change review process? If so, how do we audit what's going in and what's coming out of the Hotmail zone?

2. For Office 365, we can't publish DNS entries for most of our customers. We could tell them what to publish but I guarantee you almost none of them would for every single mail list their users signed up for, if they had to do it every day. Most of them probably wouldn't even do it once.

That's the part that doesn't scale.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Tuesday, April 14, 2015 2:48 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Publishing and Registration Concerns

   if ADID == SDID
      DO DNS_DMARC
   else
      DNS PROBLEM TOO HARD.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Apr 2015 18:44:32 -0400

> Which is completely orthogonal to the question. Scale for this is about scaling the data collection and DNS record publishing.

Ok, so what else is different for any DNS based application?  It is 
far more simpler to

DMARC+TPA/ATPS method:

   1a) Publish your ADID+SDID zone record,

   1b) Have Receivers do a ADID+SDID lookup for existence. A positive 
result
       provides the SDID authorization as a signer.

then use a dual signature @FS=SDID method:

   2a) Change signer code to add a secondary signature, lets assume 
the simpler
       do it for all, the global vs selective dual signing.

   2b) Change the receiver to look for @fs=SDID logic and use this 
explicit
       signature as an implicit indication that ADID authorizes the SDID.

In both cases, you got an extra DNS check. i don't think you will have 
everyone doing 2a as a global outbound dual signer, but lets say thats 
done by most, now you have the incentive for the bad guys to create 
fake facsimiles of replayed mail.  You don't have this under #1.

> My essentially one person domain would have a more complex forwarder/mailing list list than the SPF records of even the largest providers.

Ok.  I have a feeling you would be fine, :) nonetheless.  If exposure 
with @FS=SDID is ok, and looking directly for the SDID under the ADID 
zone is functionally the same, then why should companies who are 
perfectly capable of scaling and managing the ADID/SDID zone be 
limited to a more weaker more costly code changing solution?

Why is there a presumption that this "scale" problem is universal?

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Apr 2015 16:02:07 -0700

> My essentially one person domain would have a more complex forwarder/mailing list list than the SPF records of even the largest providers.
Dear Scott and Terry,

We had a similar effort focused on world wide abuse that had
more than 100 collection points.  Processing was automatic
and would generate needed zone files in a sequence repeating
every 15 minutes administrated by two people.  DMARC can be
setup to offer similar inputs which need to be compared
against a collection of outbound logs.  By avoiding the use
of SQL, the process should complete with plenty of time to
spare using a typical server.  Spam traps in addition to
DMARC feedback would detect abuse.  No guesswork should be
involved when done right.  There was a larger staff handling
logged communications aimed at abuse mitigation.  A
thankless job that must be done.  I was shocked to hear a
bulk sender at a recent conference say no one reads their
abuse@ mail.  I don't recall the provider.

There are a few ways to reduce the complexity for each
entity performing this process.

Domains sharing a similar relationship to your domain could--

a) copy a list of mediators requiring DMARC exceptions.
b) find a provider that maintains a _tpa list and delegate
your _smtp._tpa. zone.
c) find a provider that maintains a _tpa list and then
synthesize CNAME responses. See RFC2672.
d) find a provider that both maintains a _tpa list and that
supports  Non-Terminal DNS Name Redirection (DNAME).

Even use of draft-levine-dkim-conditional will require a
similar list be created to reduce both risk and overhead. 
Publishing this list in DNS ensures it can safely be
distributed and handle the needs of SMTP.  SQL methods may
not be sufficient.  When things go wrong because
DKIM-Conditional becomes exploited, you could save the show
by having a _tpa zone as a fall back.  Murphy's Law, 
"Whatever can happen will happen."

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Apr 2015 20:03:23 -0400

On April 14, 2015 6:44:32 PM EDT, Hector Santos <[email-masked]> wrote:
>> Which is completely orthogonal to the question. Scale for this is
>about scaling the data collection and DNS record publishing.
>>
>

The difference is that in the second one the originator isn't required to have a comprehensive list of mediators in advance. I agree describing such a list in DNS wouldn't be that hard.  The problem is creating and maintaining such a list for domains with non-trivial numbers of users. That includes the complexity of explaining to most of these users what a mailing list is.

>> My essentially one person domain would have a more complex
>forwarder/mailing list list than the SPF records of even the largest
>providers.
>

I could do it, but I'm pretty sure I'd categorize it as more trouble than it's worth. 

How many different schemes do you think receivers will deploy? I think we get at most one solution that requires changes at the sender and receiver. Whatever it is needs to work as broadly as possible. Even if your approach would work for small domains, I think it needs to work for large providers too to be worth pursuing. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Apr 2015 13:57:34 -0400

Hi Terry,

I understand your point.  Just consider, Microsoft still has its DNS 
TXT record for its original Caller ID for Email Protocol (CEP), the 
original clone of SPF that eventually became Sender-ID:

   D:\Users\Administrator>lmap _ep.hotmail.com
   Server:  ns.santronics.com
   Address:  208.247.131.210

   Non-authoritative answer:
   _ep.hotmail.com text =

      "<ep xmlns='http://ms.net/1' testing='true'>
        <out>
        <m>
        <indirect>list1._ep.hotmail.com</indirect>
        <indirect>list2._ep.hotmail.com</indirect>
        <indirect>list3._ep.hotmail.com</indirect>
        </m>
        </out>
      </ep>"

Early on, MS application developers were high on using XML, it was 
being explored for both program and data.  Thats just to show you of 
the DNS changing mindset for accepting the additional overhead and 
increasing usage for app developers.  The fact it hasn't been removed 
(and please don't yet, I like keeping it for prosperity), shows there 
is still some corporate/DNS controls.  I do know that hotmail.com was 
acquired so that might still mean something people/team wise.

Overall, I believe you are missing the software tools to manage this. 
Like most DNS applications like this, it still required the tools.

However, my point, other than believing MS has the resources and power 
to do this, when it comes to the protocol itself, it should not, and 
it is generally isn't, a reason for excluding such a natural protocol 
idea like this even as a protocol option.  Its a natural fit to detect 
1st vs 3rd party and make authorization decisions.

Finally, consider that its not always applicable across all email 
applications, especially for the larger public service area as you 
pointed out.  But it still applies for many of the other mail hosting 
systems including other Microsoft email applications.  For example, 
the MS Security Bulletins it has message ADID and SDID values such as:

      DKIM-Signature: d=email.microsoftemail.com
      From: e-mail.microsoft.com

That is a third party.  All you need to do is add a ATPS DNS TXT record:

     base64(sha1("email.microsoftemail.com")._atps.e-mail.microsoft.com

and manage it of course. No code change is necessary on your end as a 
publisher and signer.  The change is for DMARC receivers to add a 
extension to the lookup logic.  Based on RFC4686 (Security threats 
Analysis) and RFC5016 (Requirements), the consensus which was also 
reflected by the APIs written, it used a  ADID != SDID condition to do 
a POLICY lookup.

So you can apply this.  Harder for Hotmail.com, well understood, but 
not for microsoft.com which has a strong policy with known senders. 
Your SPF policy reflect this.   For signers, well, you need 3rd party 
logic before e-mail.Microsoft.com flips the DMARC p=reject switch.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Apr 2015 11:08:47 -0700

On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink <[email-masked]>
wrote:

> 1. For Hotmail, every mailing list that our users are signed up for would
> result in a new DNS entry. How do we manage the lifecycle around that?
> Should we automate its addition? Should we automate its removal? Do we
> delay email before the DNS entries are published? Should we thereby bypass
> the change review process? If so, how do we audit what's going in and
> what's coming out of the Hotmail zone?
>
> 2. For Office 365, we can't publish DNS entries for most of our customers.
> We could tell them what to publish but I guarantee you almost none of them
> would for every single mail list their users signed up for, if they had to
> do it every day. Most of them probably wouldn't even do it once.
>

+1.  The mechanism of generating DNS records is not the issue; we even have
an RFC that shows how that could be done in theory.  It's the processes
themselves that simply won't scale or would fail to thrive.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Apr 2015 14:41:36 -0400

> themselves that simply won't scale or would fail to thrive.

-1.

There is no proof of this other than it hasn't been tried at large 
scale. Nonetheless, software guys can produce the tools for anyone to 
do this, today, successfully.  Once again, by far, and I hope you 
agree, most domains will not need the level of scale that would begin 
to make it too complex to manage.  Not everyone has the "complex 
processes" which I believe has been overblown and used as a flat out 
reason for excluding the most feasible idea we have.

 From a pure protocol standpoint,  it is a natural fit. We are talking 
about satisfying the ADID != SDID condition lacking in DMARC which can 
be a protocol option:

      DMARC Receivers MAY use DSAP mechanisms for ADID != SDID conditions.

which can translate into product configuration options.

    [X] Support DMARC
        [X] Support ATPS Extension
        [X] Support @FS=
            (o) Global (sign all)
            (_) Selective (Disabled, Future)

It is unreasonable to impose more complex changes to both signers and 
receivers, all of them, with no option to do a simple lookup which is 
all that is required.  I am open to having both a direct and inband 
methods with direct being the most efficient and least costly.   You 
can not impose costly changes on all when it is clearly not necessary.

IMV, the IETF should not be in a put into position where it is 
creating situations for Mail and DNS folks to battle over the highly 
subjective belief that it is just too hard to manage DNS records, thus 
lets make the mail less DKIM secured and more DKIM complex with more 
in-band (RFC5322) information.  It isn't going to fly too well.

-- 
HLS

---

From: Terry Zink <[email-masked]>
Date: Wed, 15 Apr 2015 19:26:16 +0000

> For example, 

This is something we've done many times, except that rather than creating an ATPS record, we just add the 3rd party's IPs to a subdomain's SPF record (e.g., email.microsoft.com or e-mail.microsoft.com) and set up DKIM keys for it, and then tell the 3rd party to send email that way. The example you have is not aligned because I haven't done every domain within Microsoft, but if I ever get to this one, that's how I'll do it.

> and manage it of course.

And herein lies the trouble. "Manage it of course" is more than a simple line of text. If I want to add a 3rd party to Microsoft's zone:

1. I need get sign off from necessary parties
2. I create a DNS change request
3. It goes through a review process
4. I have to review the zone updates since I created the tickets
5. They usually ask me to validate it manually when the Ops team does the change.

None of this process is automated, and that's intentional. Instead, we make deliberate changes to the Microsoft zone so we know what's going in.

By contrast, the ATPS for 3rd parties - mailing lists - is not something we would automate. I know of a few mail servers that other employees use that relays email as @microsoft.com in the From: address that will fail DMARC. But if we had to add every 3rd party mailing list that employees used, we'd have to go through this change review process each time. But because employees signing up for a mailing list is not official company business, we *wouldn't* update our zone just for that without a good reason.

Similarly, for Hotmail, would we really want to update our zones automatically for every mailing list a subscriber signs up for? Without any change control? I'm inclined to say no.

-- Terry

-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2015 10:58 AM
To: [email-masked]; Terry Zink
Subject: Re: [dmarc-ietf] Publishing and Registration Concerns

Hi Terry,

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 15 Apr 2015 16:39:13 -0400

> in-band (RFC5322) information.  It isn't going to fly too well.

For the umpteenth time, the issue isn't managing a DNS zone.  That's the easy 
part.  The hard part is knowing what to put in it.  Many companies, not even 
the really big ones, have thousands of domains.  Go publish SPF, DKIM key, and 
DMARC records for 4,000 domains and then tell me it's all easy to then figure 
out what the right list of authorized forwarders should be for each one.

ScottK

P.S.  I'm done on the topic of is keeping a list of forwarders a useful 
solution for the group to work on.  No matter how you wrap it up, it's not.

---

From: Terry Zink <[email-masked]>
Date: Wed, 15 Apr 2015 21:10:21 +0000

> out what the right list of authorized forwarders should be for each one.

+1.

-- Terry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Apr 2015 15:11:50 -0700

+1.

Also, if one were to interpret the Pareto Principle correctly, it actually
favors the idea that the only things we should consider are the ones the
large operators are willing to adopt, which means it's abundantly clear
that registration protocols -- all of them -- are non-starters at this
point.

+1.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Wed, 15 Apr 2015 16:51:09 -0700

On Apr 15, 2015, at 3:11 PM, Murray S. Kucherawy <[email-masked]> wrote:

> On Wed, Apr 15, 2015 at 1:39 PM, Scott Kitterman <[email-masked]> wrote:
> Also, if one were to interpret the Pareto Principle correctly, it actually favors the idea that the only things we should consider are the ones the large operators are willing to adopt, which means it's abundantly clear that registration protocols -- all of them -- are non-starters at this point.
> 

+1

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Apr 2015 20:47:54 -0400

On 4/15/2015 4:39 PM, Scott Kitterman wrote:
> part.  The hard part is knowing what to put in it.

Right. I never said it was hard problem.  This didn't stop the large 
domain with SPF in adding INCLUDE and still have an unknown result.

>Many companies, not even
> the really big ones, have thousands of domains.

and millions more does not.

> Go publish SPF, DKIM key, and  DMARC records for 4,000 domains and then tell me
> it's all easy to then figure out what the right list of authorized forwarders
>should be for each one.

For the umpteenth time, not everyone need 4000 domains. Most of the 
domains that will or may utilize it, simply don't need this scale.

> solution for the group to work on.  No matter how you wrap it up, it's not.

So move on, scott.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Apr 2015 20:51:20 -0400

> that registration protocols -- all of them -- are non-starters at this

Well, you interpreted it incorrectly.  If that was the case, many IETF 
protocols would of never got off the ground.

-- 
HLS

---

From: Terry Zink <[email-masked]>
Date: Thu, 16 Apr 2015 00:55:30 +0000

Hi, Hector,

> domains that will or may utilize it, simply don't need this scale.

I'm not sure you get the point that the others are trying to make. While this *may* scale for small domains (a big maybe), it won't scale for large domains like Hotmail, Yahoo, Google, AOL, and a lot of other large providers who are unlikely to implement it. They make up a small number of implementers but a massive number of users. If it won't work for this massive user base, then it's not worth implementing even on a small scale because for the average user (of which there are millions), the people they try to send to (Hotmail, Google, Yahoo) aren't supporting this.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Wednesday, April 15, 2015 5:48 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Publishing and Registration Concerns

So move on, scott.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Apr 2015 08:20:27 -0400

On 4/15/2015 8:55 PM, Terry Zink wrote:
> I'm not sure you get the point that the others are trying to make. While this *may* scale for small domains (a big maybe),

Terry,

Its not a "big maybe."  Its in production code.  It already been shown 
to scale. Smaller, even mid size organizations are simply not going to 
have this registration problem.  Most domains are not going to need 
millions, nor thousand and probably not even hundreds of domains. Even 
if they did, its manageable.

> ... it won't scale for large domains like Hotmail, Yahoo, Google, AOL, and a lot of other large providers who are unlikely to implement it. They make up a small number of implementers but a massive number of users. If it won't work for this massive user base, then it's not worth implementing even on a small scale because for the average user (of which there are millions), the people they try to send to (Hotmail, Google, Yahoo) aren't supporting this.
>

You know, I'll leave it at this.

The same was said that no one will implement DKIM Policy ideas.  And 
even if they did, it was said, that no one will use prepare hard 
policies, and even if they did, it was said, no one will turn on the 
rejection switch, that no one will honor it, especially the MLM.

Well, we are here because it did happen. Questionable decisions were 
made in the past to abandoned policy ideas and its being repeated again.

If the only problem is registration, this is not a reason to limit the 
protocol to just 1st party lookups.

Finally, to use "large providers" arguments is generally not how IETF 
protocols are designed.   I I will even suggest it borderlines 
conflict of IETF interest.  There are millions of private operation 
domains and quite a few SMTP implementators.  Not everyone uses Office 
365, Hillary had her own servers :).   They all will not have this 
registration issue and the protocol makes good engineering sense 
across the board. The direction the WG is headed is not only more 
unsecured but will exert more cost and pressure on everyone else. 
Thats not good, especially when the decision is the leave out the best 
idea we have for ALL kinds for systems, not just the big guy.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Apr 2015 13:57:43 -0700

Dear Terry,

Since DMARC assertions cause compliance issues for
third-party domains, and since some think customers would be
unable to manage a third-party exception list needed for
draft-otis-tpa-label, draft-levine-dkim-conditional,
draft-kucherawy-dkim-delegate, and rfc6541, one solution
would use DMARC assertions to delegate the heavy lifting to
a separate organization specializing at handling third-party
conflicts.  That would allow all of their customers to
expend little effort in their system configuration such as
_dmarc TXT "v=DMARC1; p=quarantine;
tpa=third-party-authority.com;

This way, the most that administrator would concern
themselves with is dealing with is simple TXT records from
their perspective.  Perhaps hotmail might even offer their
zone on a fee basis.  It also seems like an ideal way to
ensure your customers are likely to remain happy and not
leave.  I would be happy to make tpa-label look more like
atps, but I don't think the reasons for the additional terms
were clearly understood.  These terms ensure third-party
messages could be differentiated from direct mailing using
simple sort criteria.

It would be equally wrong to suggest anything included in
the dkim-conditional header would be indicating exactly what
a malefactor needs to add to their message for acceptance.
More on that later.

Regards,
Douglas Otis