Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

From: Anne Bennett <[email-masked]>
Date: Wed, 01 Apr 2015 10:35:28 -0400

J. Gomez <[email-masked]> writes:

> a "technically appropriate" technical solution yes there is:
> "Every resender[ *] who invalidates the original Author's DKIM
> signature must take ownership of the Header-From and re-sign
> the message". Simple. Easy. But socially unacceptable (for
> now, at least) because of the expectations of several legacy
> mail usages.

If by "expectations of several legacy mail usages" you mean
"reasonable expectations of well-established mail usages",
and not "unreasonable expectations of nearly-obsolete mail
usages", then sure.  :-)

So having granted that the above proposed solution is
unacceptable, how can we move on to find an acceptable solution?

Some days ago I tentatively suggested signing only part of
some message parts, in particular part of the Subject header
(excluding any future additions of "[list-identification]"),
assuming that such an approach had doubtless already been
suggested elsewhere.  I was expecting to hear either "been
there, tried that, won't work", or (a polite version of) "that's
a dumb idea because...", but I've heard nothing.  I can't quite
make myself believe that you're all rendered speechless by my
sheer genius, so... why *won't* something like that work?

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 1 Apr 2015 14:40:57 +0000

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Anne Bennett
> Sent: Wednesday, April 01, 2015 10:35 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
> 
> 
> > signature must take ownership of the Header-From and re-sign the
> > message". Simple. Easy. But socially unacceptable (for now, at least)
> > because of the expectations of several legacy mail usages.
> 
> If by "expectations of several legacy mail usages" you mean "reasonable
> expectations of well-established mail usages", and not "unreasonable
> expectations of nearly-obsolete mail usages", then sure.  :-)
> 

This will be extremely difficult.

> So having granted that the above proposed solution is unacceptable, how
> can we move on to find an acceptable solution?
> 
> Some days ago I tentatively suggested signing only part of some message
> parts, in particular part of the Subject header (excluding any future additions
> of "[list-identification]"), assuming that such an approach had doubtless
> already been suggested elsewhere.  I was expecting to hear either "been
> there, tried that, won't work", or (a polite version of) "that's a dumb idea
> because...", but I've heard nothing.  I can't quite make myself believe that
> you're all rendered speechless by my sheer genius, so... why *won't*
> something like that work?
> 

Signing only part of a message (whether body or only part of headers such as subject) invites abuse through replay attacks. This is one of the reasons that "l=" pretty much went by the wayside.

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Apr 2015 07:53:20 -0700

On 3/30/2015 12:01 PM, Steve Atkins wrote:
> It's not particularly difficult to make DKIM and SPF work if you have full
> control over the domain name you're sending from (and some control
> over the delivery path).

Forgive my focusing on precise wording, but 'sending from' can have
enough different, valid meanings to permit some confusion, so I suggest
language that is a bit more cumbersome but precise:

     It's not particularly difficult to make DKIM and SPF work if you
have full control over the domain name that is used in the rfc5322.from
(author) field in the message header (and some control over the delivery
path).

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 1 Apr 2015 17:20:37 +0200

> unacceptable, how can we move on to find an acceptable solution?

It is an "unacceptable" solution, for now at least because of the incumbency said legacy mail usages still hold.

If no better "solution" is found now when formalizing DMARC, I guess the slow but unstoppable dynamics of reality will decide the matter for us in about 10 or 15 years (much as SPF needed a lot of time to be generally used and nowadays more and more people are publishing "-all").

Regards,
J.Gomez

---

From: Steve Atkins <[email-masked]>
Date: Wed, 1 Apr 2015 08:27:07 -0700

> On Apr 1, 2015, at 07:53, Dave Crocker <[email-masked]> wrote:
> 

In the context of reduced SPF and DKIM functionality as required for use with DMARC, sure.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Apr 2015 08:31:20 -0700

> sheer genius, so... why *won't* something like that work?

I missed the earlier suggestion.

As I recall this was considered during the development of DKIM originally,
exactly for this reason.  We rejected it because we couldn't come up with a
safe description of what a tag should look like.  If arbitrary text is
allowed in there, then one could "tag" a spam URL at the front of a
legitimate message's Subject field and the signature would still pass.  If
you assert a length limit on the size of a tag, then lists out there that
use some longer mnemonic to identify the list are excluded.  If you assert
no special characters are allowed, you exclude international list names.
Not all list tags use the square brackets at the front as delimiters.  Et
cetera.

Short of introducing legislation about what constitutes a "standard" set of
list modifications, which would be highly controversial and consensus
firmly disliked, there wasn't a good path forward there, so the working
group dropped the idea.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Apr 2015 08:31:27 -0700

On 4/1/2015 8:27 AM, Steve Atkins wrote:
> n the context of reduced SPF and DKIM functionality as required for use with DMARC, sure.

Wasn't that that was the context of the thread?

And one of the useful things about the wording I suggested is that it
doesn't rely on context.  It's always accurate and precise and clear.

d/

---

From: Steve Atkins <[email-masked]>
Date: Wed, 1 Apr 2015 08:56:30 -0700

> On Apr 1, 2015, at 08:31, Dave Crocker <[email-masked]> wrote:
> 

The message being discussed wasn't from a domain that was using DMARC, though that's usually an implicit context on a dmarc mailing list.

> doesn't rely on context.  It's always accurate and precise and clear.

It's clear, but I don't think it's accurate unless you include the context of DMARC alignment.

Controlling the domain used in the 5322.from doesn't allow me to do SPF or dkim authentication, as they don't key off that domain.

To be able to authenticate I need to control the domain used in the return path or dkim d= - just controlling the 5322.from itself doesn't allow me to send authenticated mail using that domain.

As a concrete example, if I send mail with a 5322.from of [email-masked] through a typical small esp that uses a bounce.esp.com return path and signs with d=esp.com then I cannot authenticate that email, despite having full control over the domain used in the 5322.from.

Cheers,
  Steve

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 1 Apr 2015 16:15:50 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Wednesday, April 01, 2015 11:56 AM
> To: [email-masked]
> The message being discussed wasn't from a domain that was using DMARC,
> though that's usually an implicit context on a dmarc mailing list.
> 
> >
> Controlling the domain used in the 5322.from doesn't allow me to do SPF or
> dkim authentication, as they don't key off that domain.
> 
> To be able to authenticate I need to control the domain used in the return
> path or dkim d= - just controlling the 5322.from itself doesn't allow me to
> send authenticated mail using that domain.
> 
> As a concrete example, if I send mail with a 5322.from of [email-masked]
> through a typical small esp that uses a bounce.esp.com return path and signs
> with d=esp.com then I cannot authenticate that email, despite having full
> control over the domain used in the 5322.from.
> 

That's an operational choice Steve. You could provide them a private DKIM key so they could sign d= with your 5322.from domain signature. If they aren't willing to do that and you are concerned about abuse of your domain then you find another vendor. Places you have a contractual relationship with are much easier to resolve than random 3rd parties.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Apr 2015 12:50:40 -0400

> firmly disliked, there wasn't a good path forward there, so the working

That matches my recollection.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2015 18:11:14 -0000

>safe description of what a tag should look like. 

Yeah, that's what I recall, we couldn't figure out a way to allow benign
modifications without also allowing spammy ones.

Has anyone looked at my double signing draft?  The idea is the the
original sender (which we'll call, oh, Yahoo) puts on a very weak
signature probably only on From, Date, and Message-ID, with l=0 and a
new tag that says the signature is only valid if the message is also
signed by a specific other domain, call it ietf.org.  It probably also
puts on an ordinary strong signature, too, and sends the message to a
list forwarder such as [email-masked].  The list does what it does,
and signs the message normally with d=ietf.org.  That breaks the
strong yahoo signature, but the weak one is now valid in combination
with the normal ietf.org signature, so there's a valid d=yahoo
signature and DMARC is happy.

The forwarder could of course do naughty things, but only the specific
forwarder to whom the message was sent, which greatly limits the scope
of damage. It's even more limited in the common case that the original
sender has a reasonably good idea who are likely to be the well
behaved forwarders and only puts the weak signatures on mail sent to
them.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 1 Apr 2015 11:11:47 -0700

> On Apr 1, 2015, at 9:15 AM, MH Michael Hammer (5304) <[email-masked]> wrote:
> 
> 
> 

Dear Mike,

View this issue from the perspective of those offering forums 
and who provide recipients a means to identify authors and to 
sort messages.  Most individuals do not own their From domain 
and instead rely on services offered by their broadband provider.  
It is fairly unlikely either organizations or individuals will 
offer private keys or authorize all source IP addresses to 
support all possible forums on a large scale.  Neither DKIM nor 
SPF accommodate such use based on current DMARC constructs, even 
assuming contractual issues are not imposed on behalf of clients 
or providers. 

In that sense, DMARC (ab)use can not be remedied by practical 
operational choices, which DMARC should be able to support.
I-D to follow.

Regards,
Douglas Otis

---

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

> behaved forwarders and only puts the weak signatures on mail sent to

Didn't we stalemate on the question of whether this has to be a whole new
header field, or a "v=" increase?  I seem to recall someone (Dave?)
thinking both were horrible.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 14:36:31 -0400

> thinking both were horrible.

That was certainly a question, but I don't recall any consensus on 
realtive horribility.  I like v=2, that's what version bumps are for.

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

---

From: Michael Jack Assels <[email-masked]>
Date: Wed, 01 Apr 2015 21:00:19 -0400

On Wed, 01 Apr 2015 11:20:50 PDT, 

> thinking both were horrible.

To avoid a new header field or a "v=" increase, to make DMARC failure a really
reliable indication of genuine invalidity, at least where mailing lists
are concerned, why not focus on the fact that RFC5322.From headers clearly
allow multiple addresses, and invite Mediators such as mailing list to take
responsibility for their changes by adding an address in their own domain
to the RFC5322.From header and adding their own DKIM-Signature?

RFC7489 seems to hem and haw a bit about multiple From addresses (in a 
single From header).  E.g., in Section 6.6.1:

   o  Messages bearing a single RFC5322.From field containing multiple
      addresses (and, thus, multiple domain names to be evaluated) are
      typically rejected because the sorts of mail normally protected by
      DMARC do not use this format;

and a little later in the same section:

   The case of a syntactically valid multi-valued RFC5322.From field
   presents a particular challenge.  The process in this case is to
   apply the DMARC check using each of those domains found in the
   RFC5322.From field as the Author Domain and apply the most strict
   policy selected among the checks that fail.

(The word "fail" leaves me confused.  Shouldn't that be "pass"?)

At any rate, it seems to me that if DMARC would be satisfied by a Mediator
making substantial modifications to my message, changing the RFC5322.From
to

   From: "Michael Jack Assels" <[email-masked]>

and signing appropriately, it ought to be similarly happy with

   From: "Michael Jack Assels" <[email-masked]>,
         "dmarc" <[email-masked]>
   Sender: "dmarc" <[email-masked]>

signed by IETF's sending MTA.  Assuming that the usual change is made to
the Subject line and the usual trailer is appended to the message body,
only the "ietf.org" identity ought to align with "the" RFC5322.From domain,
and I can't see a reason why DMARC wouldn't be happy.  Yes, someone could
have spoofed my address, but IETF's receiver will have had an opportunity
to check that, so it's either IETF's fault for accepting the original message
or my MTA's fault for not being DMARC compliant.

In this case, the mailing list would be doing what's asked of it by DMARC,
but keeping (most of) it's time honoured values intact.

MJA

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 22:04:56 -0400

> to the RFC5322.From header and adding their own DKIM-Signature?

I believe we looked at that and decided it wasn't promising.  The problem 
is that bad guys can do whatever good guys can do:

From: [email-masked], [email-masked]
Subject: Urgent security alert about your Paypal account!
DKIM-Signature: ... d=rbn.ru

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Apr 2015 19:24:53 -0700

> realtive horribility.  I like v=2, that's what version bumps are for.

Version numbers are superfluous or inappropriate overhead.  That is,
they are either useless or else the wrong solution to demultiplexing
amongst alternate protocols.

When a protocol is revised, there are two possibilities:

     Upward Compatible: The old version of the protocol interworks with
the new version.  So the new protocol is a superset of the old.  In this
case, the enhancements typically self-identify, as new parameters or new
values for existing parameters.

     Incompatible:  The old and new don't interwork.

In the first case, the version field is literally useless.  It is wholly
redundant or worse insufficient, given that the receiver of the protocol
data unit sees the new stuff in other ways than the version field.

In the latter case, it's really an entirely new protocol, which should
be identified by the next-lower protocol, rather than by using the
version field as an in-bred demultiplexing field.

And yes, IPv4 and IPv6 are distinguished by different demultiplexing
values in the Ethernet frame:

     http://en.wikipedia.org/wiki/EtherType

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Apr 2015 19:59:16 -0700

> (The word "fail" leaves me confused.  Shouldn't that be "pass"?)

DMARC's "p=" describes the action to take when the evaluation mechanism
fails.  There is no policy to apply (other than, I suppose, an implicit
"accept" action) when DMARC passes.

> but keeping (most of) it's time honoured values intact.

This could work, except that if this yields favorable treatment by the
receiver, then that's all an attacker needs to do to get to your inbox
(i.e., double up the From: using an arbitrary domain name, and make sure
the message satisfies the DMARC test for the latter).

The exception to that is some expression, which the receiver can confirm,
that domain2 and domain1 have some kind of relationship that's interesting
to this process.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 23:02:04 -0400

> that domain2 and domain1 have some kind of relationship that's interesting

Right, which brings us back to my double signing approach.  It's looking 
like the worst option except for all of the others.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Apr 2015 20:03:07 -0700

>      http://en.wikipedia.org/wiki/EtherType

This argues for creating a new thing that looks almost identical to DKIM,
using a new header field name, that has this one extra property.  That
forces demultiplexing one pseudo-layer down.  I think John produced a draft
about that as well.

I can't get my head around the "entirely new" part of that assertion though.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2015 03:22:27 -0000

>version field as an in-bred demultiplexing field.

I suppose, but if the two procols are 99% the same, and the new one is
upward compatible with the old one, and anything that understands the
new one also has to understand the old one, and the goal is to have
everything puts semantics on the old one put the same semantics on the
new one, I'm having trouble seeing why one of these is vastly
preferable to the other:

 DKIM-Signature: v=2; d=example.com; ...
 DaveKIM-Signature: v=1; d=example.com; ...

In this particular case, the incompatibility is a new kind of "must
handle" tag suggested by Ned Freed with the new rule that if a
verifier doesn't understand it, the verification fails.  The first of
them would be must-re-sign, which means that the message has to be
re-signed by another domain, e.g.:

 DKIM-Signature: v=2; d=yahoo.com; @mr=ietf.org; ...

which would say this signature is only good if there is also a DKIM
signature with d=ietf.org.  You could chain these things which might
deal with the educational forwarding issue that Elizabeth Z. described.

Once you have the syntax for must handle tags (I used @ here) then we
can add more of them as needed without another version bump.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Apr 2015 21:07:54 -0700

>     version field as an in-bred demultiplexing field.
...
> I can't get my head around the "entirely new" part of that assertion though.

Absolutely trivial idea:

     If two networking implementations are properly conforming to mature
and debugged specifications, but the implementations cannot
interoperate, then the specifications are for different protocols.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Apr 2015 21:22:22 -0700

> upward compatible with the old one, and anything that understands the

'Upward compatible' was carefully distinguished from 'different protocol'.

Upward compatible says that the new one is a superset of the old one.
That is, all the old stuff is the same, but there's some /additional/
stuff.  The pattern is that the new stuff self-distinguishes.  In which
case the version field provides no useful information.

Worse, the usual model of enhancement is a series of increments, where
the increments often need to be used in different combinations.  Each
bit of increment needs to self-identify so that the receiver knows which
enhancements are being used.  Version fields don't support
combinatorials like that.

>  DaveKIM-Signature: v=1; d=example.com; ...

Nice example of useless version info.  The fieldname provides all the
distinguishing information that's needed, for the differential syntax
and/or semantics.

The reason it is better to use fieldname is because the engine that
decides how to dispatch to code that understand the contents of a field
only needs to look at the fieldname, rather than the fieldname and the
version field.

> verifier doesn't understand it, the verification fails.  The first of

Right.  So an older implementation sending to a newer one is trying to
talk a different semantic than the newer one requires.  Hence, they do
not interoperate.  Hence the demultiplexing between them should be in
the lower-layer dispatcher.  In the case of a DKIM-bis-ish change, that
means a different header field name.

It really is a different protocol.

> deal with the educational forwarding issue that Elizabeth Z. described.

What you have described is an overlay protocol.  It logically sits above
DKIM, since in additional to doing it's own thing, it "uses" DKIM.  The
fact that it looks quite a bit like DKIM is a distraction.  It has an
essentially different semantic.

Remember that chimpanzees have almost all the same genes as humans.  But
they aren't human.  Or perhaps we aren't chimpanzees. (Well, most of us
aren't.)

> can add more of them as needed without another version bump.

Changing the must-implement set changes the basic protocol into a new
protocol.  Adding optional ones doesn't.

d/

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Apr 2015 07:49:46 -0400

> to the RFC5322.From header and adding their own DKIM-Signature?

Which address would be first?  The 3rd party or the first party?  Will 
the 3rd party first do a POLICY check to determine is this is allowed? 
  Maybe the first party doesn't want or expect any 3rd party signature?

I think the MLS/MLM needs to first respect the wishes of the 1st party 
before trying to circumvent the security by modifying the 5322.From.

>     policy selected among the checks that fail.

While it is technically allowed by 5322. I have yet to see this in the 
wild and many software components simply are not ready for such 
multiple From field, especially at gateways and transformations or 
online hosting systems or MUAs where only one from is expected.

> to ....

Its far easier to just a DNS lookup of the 1st party to determine if 
the 3rd party is a trusted, authorized resigner, "mediator."

      YesNo =  Is_Signer_Authorized(Author, Signer)

Far easier and least expensive solution.

-- 
HLS

---

From: Anne Bennett <[email-masked]>
Date: Thu, 02 Apr 2015 09:59:55 -0400

> legitimate message's Subject field and the signature would still pass.

Right, but if that tag were explicitly deemed to be excluded
from the signature, it could be handled differently.  Hmm, but
if this resulted in (for example) the tag not being displayed,
then we would have gained nothing in the case of mailing lists.

> list modifications, which would be highly controversial

Unlike, say, having mailing lists munge the "From:" header.  ;-)

> and consensus

... but okay, in view of the fact that this idea ends up not
really gaining us much in terms of allowing mailing lists to
tag their messages,  I'll drop it.

Anne.

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2015 14:48:50 -0000

>'Upward compatible' was carefully distinguished from 'different protocol'.

It occurs to me why this is still DKIM -- the external interface is
the same.  You call a DKIM verifier by, roughly, giving it a mail
message, and it tells you what the d= was on the valid signatures.
That doesn't change.  Anything that uses DKIM v1, whether it's DMARC
or a Spamassassin plugin, uses v2 the same way.

On the signing side, the signer has the new option of adding a conditional
signature, but all of the old options still work.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Apr 2015 08:05:54 -0700

> signature, but all of the old options still work.

Protocols are defined by bits over the wire, not APIs.

The most striking example of this point that I had to deal with was
NetBIOS.

IBM published the API but not the protocol.  A few different LAN
companies each created their own proprietary protocols that conformed to
the API, but which were wildly different from IBM's and each other's.

The fact that the new ones all ran over TCP didn't matter:

     They Did Not Interoperate.

Eventually there was market pressure to interoperate and we were forced
to collaborate on the development of RFC 1001/1002.(*)

FWIW this confusion about the nature of 'upgrades' is a relatively
consistent pattern over the years.  It plagued some of the recent
internationalized email work, which bogged down in trying to define both
a new mode and the shared operation with new and old modes.  And it
plagued IPv4/IPv6, although in the reverse direction: v6 could have been
an almost-compatible upgrade, which would have made gatewaying trivial
and deployment probably 15 years earlier...

d/

* It was also my introduction to the difference between skills in
implementing a protocol specification, versus skills in designing one.
Being quite good in the former was no prediction of competence in the
latter...

---

From: "John R Levine" <[email-masked]>
Date: 2 Apr 2015 11:14:03 -0400

> Protocols are defined by bits over the wire, not APIs.

They're defined by both.  The main reason we published RFC 5672 was to 
clarify that the API returns the value of the d= tag, not the i= tag, 
even though the bits on the wire didn't change.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Apr 2015 08:42:36 -0700

On 4/2/2015 8:14 AM, John R Levine wrote:
> They're defined by both. 

Sorry, no.

Or rather, while it is common to link them together, that's not required.

Just as the same API can be satisfied by many different protocols, the
same protocol can be accessed through many different APIs.

Historically the IETF has tried to focus only on protocols (bits over
the wire), in order to stay away from API wars and the differences
needed by different platforms.  In recent years, this has been relaxed
somewhat, mostly serving to add to the confusion about the difference
between APIs and protocols (IMO).

I haven't done a careful audit, but the IETF typically does not put API
specs on standards track, though I note that the Kerberos GSS-API comes
close.  Except that it is specified as... a protocol.

> The main reason we published RFC 5672 was to

That's not why I initially raised the issue that led to the creation of
the update.  I cast it in terms of overhead vs. payload, the same as I'm
distinguishing here and alas, the same as I was taught, 40 years ago.

    "DomainKeys Identified Mail (DKIM) ... permit[s] a signing domain
     to claim responsibility for the introduction of a message into the
     mail stream. "

That is, the 'payload' of DKIM is the delivery of a validated domain
name.  In the original specification, we failed to properly specify
which of the two delivered identifiers (d= and s=) was that promised
payload.

In the Update, here too we see the confusion caused by having the
document even reference the construct of an API.  Frankly I conceded the
reference in that document as a means of trying to get past people's
confusion about the difference between the parts of a protocol that are
overhead, versus that part that is payload, delivered outside of the
protocol.  Given this exchange now, I regret that concession.

d/

---

From: "John R Levine" <[email-masked]>
Date: 2 Apr 2015 12:02:19 -0400

> which of the two delivered identifiers (d= and s=) was that promised

These hairs are split too finely for me to understand.  The DKIM validator 
takes the message and the not-API returns a possibly empty list of 
identifiers.  In v2 or whatever we call it, the validator does exactly the 
same thing.

The main difference I see is that if we call v2 something else, we now 
have a tedious administrative exercise of finding every place something 
refers to DKIM and change it to "DKIM or DKIM-plus."  This does not strike 
me as a good use of anyone's time.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Apr 2015 09:18:25 -0700

On 4/2/2015 9:02 AM, John R Levine wrote:
> These hairs are split too finely for me to understand.  

You mean like the difference between a driver and a passenger?

Really, there's nothing subtle or fine about it.  In fact is a clean and
essential distinction, if the protocol is to be cleanly defined.

In classic networking architecture hierarchies, an exchange is
characterized by defining provider and a consumer.  The former wants to
supply some information to the latter.  That information is the payload.
 They use a protocol to do that.  The protocol is a set of rules and
formats for effecting that transfer of the payload.  Any part of the
protocol that is not payload is overhead.

> The DKIM
> validator takes the message and the not-API returns a possibly empty
> list of identifiers.  In v2 or whatever we call it, the validator does
> exactly the same thing.

Ahh, I see.  American English and British English and Malaysian English
are all identical, since they satisfy the same, generic functional
description.  For that matter, English and Russian are the same because
the do too.

Again:  The required semantics differ and...  The Protocols Do Not
Interoperate.

To make this fundamental point irrelevant, one of us first needs to be
able to mate with an orang utan.

> refers to DKIM and change it to "DKIM or DKIM-plus."  This does not
> strike me as a good use of anyone's time.

That task you characterize as tedious is, in fact, the discipline of
making sure the documentation is careful to distinguish between the two
different (ie, non-interoperable) protocols.

Efforts to do that with a single specification wind up confusing things
and confusing readers and implementers.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Apr 2015 10:59:36 -0700

> then we would have gained nothing in the case of mailing lists.

Handled by whom?  If we're talking about telling MUAs "Don't render the
unsigned part of the content the same way as the signed content", then a
bunch of additional complexities begin to appear:

- MUAs now need to know how to do DKIM themselves, so that they know what
parts were signed and what parts were not; alternatively, we need a way to
signal between the DKIM verifier and the MUA what parts are safe to render,
beyond what Authentication-Results already provides

- We're wandering into conversations about how MUAs should interact with
users, which this community typically avoids like a terrible allergy

- Even if the above aren't problems, we're relying on MUAs to adapt to this
change in a relatively short period of time

Here be dragons.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2015 18:08:07 -0000

>bunch of additional complexities begin to appear:

We went over all of this ages ago when DKIM was young.  It should all be
in the DKIM WG archives.

>users, which this community typically avoids like a terrible allergy

No kidding.  I see no reason to expect that mail recipients would do
anything useful with differently colored parts of the message.
Punting security decisions to users usually seems to train the users
to push whatever button makes the warning go away.

Also, when we went down this rathole before, we noted that MIME
provides an enormous range of ways to make both malicious and benign
changes to a message body, and l= doesn't begin to scratch the mites
on the dust on the surface.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Apr 2015 11:42:43 -0700

> and confusing readers and implementers.

I'm using API terminology here but I think the comment generalizes to the
protocol:

If the input is "the message" and the output is "a set of zero or more
SDIDs representing domains whose signatures validated", then I don't think
it matters if we go the "v=2" route or the "new header field name" route,
because the multiplexing happens on the inside of the processing machine
thus described.

However, and perhaps unfortunately, RFC5672 changed it so that the output
of DKIM is a single SDID.  That means either (a) RFC5672 got it wrong,
because this doesn't allow for the whole message to be the input and
multiple domain names (for passing signatures) to be the output, or (b) the
above definition is wrong, because it means a single DKIM signature _plus_
the whole message is the input, and the algorithm picks apart the message
as needed to complete the verification and thus produce the single SDID (or
an error).

OpenDKIM certainly implements the first definition I've used above at its
API level, though I could argue that it satisfies either of the two
definitions and just happens to do the latter one in a parallel way.

-MSK

---

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

> because the multiplexing happens on the inside of the processing machine

As I read RFC6376 sections 3.8 and 3.9, this is a valid perspective.  (I
may be biased.)

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 02 Apr 2015 21:42:05 +0200

On 04/02/2015 07:59 PM, Murray S. Kucherawy wrote:
> On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Handled by whom?  If we're talking about telling MUAs "Don't render 
> the unsigned part of the content the same way as the signed content", 
> then a bunch of additional complexities begin to appear:
>
> - MUAs now need to know how to do DKIM themselves, so that they know 
> what parts were signed and what parts were not; alternatively, we need 
> a way to signal between the DKIM verifier and the MUA what parts are 
> safe to render, beyond what Authentication-Results already provides
>
> - We're wandering into conversations about how MUAs should interact 
> with users, which this community typically avoids like a terrible allergy
>
> - Even if the above aren't problems, we're relying on MUAs to adapt to 
> this change in a relatively short period of time
>
> Here be dragons.

if DMARC is really the succes that dmarc.org claims it is [1] and with 
so many of the big ESPs around here [2] I fail to see why it would be so 
difficult to involve the MUA developers of these same ESPs?

/rolf

P.S. I only noticed today the significant organizational change of 
dmarc.org [3] and the fact that this 'new' dmarc.org has only two 
founding sponsors.

[1] 
http://dmarc.org/2015/02/dmarc-is-a-proven-tool-in-the-fight-against-fraudulent-email/
[2] http://dmarc.org/about/history/
[3] http://dmarc.org/about/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Apr 2015 12:51:30 -0700

On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld <
[email-masked]> wrote:

> if DMARC is really the succes that dmarc.org claims it is [1] and with so
> many of the big ESPs around here [2] I fail to see why it would be so

Several of them are here.  If they have better experience understanding
what actually gets through to users in terms of message safety that doesn't
reduce to, as John Levine put it, "Where do I click to make this warning go
away?", they have yet to say so.  :-)

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Apr 2015 14:25:01 -0700

On 4/2/2015 11:42 AM, Murray S. Kucherawy wrote:
> On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> SDIDs representing domains whose signatures validated", then I don't

Except that that does not describe the DKIM protocol.

A protocol is not (necessarily) and input/output engine.  It is an
interaction engine that delivers things.

DKIM delivers a single validated identifier.

With respect to the specific DKIM function, the message is overhead, not
payload.  It is part of what service to enable the payload, not be part
of it.

> However, and perhaps unfortunately, RFC5672 changed it so that the
> output of DKIM is a single SDID. 

Sorry, no.  It wasn't changed, although the precise spec language did
change.

RFC 478:

     "permitting a signing domain
   to claim responsibility for the introduction of a message into the
   mail stream. "

RFC 6376:

     "DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name [RFC1034] with the message [RFC5322], which
   they are authorized to use."

In both cases, it refers to a single domain name.  Not multiple.

If you want to validate multiple domain names, you do multiple
(independent) signatures.

The substantive change was to clarify an ambiguity in the original spec,
about /which/ of the two possible domain names that are in the
DKIM-Signature field constitutes the promised one.

> That means either (a) RFC5672 got it
> wrong, because this doesn't allow for the whole message to be the input

huh?

> and multiple domain names (for passing signatures) to be the output, or
> (b) the above definition is wrong, because it means a single DKIM
> signature _plus_ the whole message is the input, and the algorithm picks
> apart the message as needed to complete the verification and thus
> produce the single SDID (or an error).

Or (c) the whole message isn't part of DKIM payload.

 The answer is (c).

> OpenDKIM certainly implements the first definition I've used above at
> its API level, though I could argue that it satisfies either of the two

I suspect what you've just said is that OpenDKIM can process multiple
signatures and deliver a list of validated domain names.

This is one more demonstration of the difference between a protocol and
an API...

d/

---

From: Terry Zink <[email-masked]>
Date: Thu, 2 Apr 2015 21:31:35 +0000

What sorts of things do you want to see in an MUA?

- Gmail says, of messages in the spam folder, “This message is here because others marked it as spam.”
- If you enable it in Gmail, they also put a key beside authenticated messages
- Outlook.com/Hotmail has a Green Shield in the List view next to messages that are on the Green Shield list (large brand susceptible to spoofing, manually maintained) and pass authentication
- Outlook desktop says “This message was marked as spam by a filter other than the Outlook junk client”
- Outlook desktop also disables Links, Reply, Reply All, and Attachments for messages in Junk, and any message marked as Phish regardless of whether or not it is in the inbox

Within Microsoft, we’re looking at how to include some of the things in outlook.com/Hotmail into Outlook and how best to integrate safety into the overall user experience in mail clients Microsoft controls. While traditionally there hasn’t been a lot of MTA-to-MUA communication (other than Exchange and Outlook), that doesn’t need to be the case going forward.

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 2, 2015 12:52 PM
To: <[email-masked]>
Cc: [email-masked]; Anne Bennett
Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld <[email-masked]<mailto:[email-masked]>> wrote:
if DMARC is really the succes that dmarc.org<http://dmarc.org> claims it is [1] and with so many of the big ESPs around here [2] I fail to see why it would be so difficult to involve the MUA developers of these same ESPs?

Several of them are here.  If they have better experience understanding what actually gets through to users in terms of message safety that doesn't reduce to, as John Levine put it, "Where do I click to make this warning go away?", they have yet to say so.  :-)
-MSK

---

From: Douglas Otis <[email-masked]>
Date: Thu, 2 Apr 2015 14:30:51 -0700

> On Apr 2, 2015, at 11:08 AM, John Levine <[email-masked]> wrote:
> 

Dear John,

The goal is to prevent recipients from seeing non-aligned Froms signifying a domain seeking DMARC protection.  This may significantly affect third-partys causing DMARC alignment failures.  In such cases, a remedy likely requires modification of From domains.

The TPA-Label scheme envisioned a DMARC extension to assert domains seeking protection will separately authorize various third-partys confirmed by various methods.   It is now clear, ESPs (ab)using DMARC have no interest in managing exceptions, with their lack of interest likely remaining true when expecting them to add provisions for the destinations of their user's messages. 

I'll attempt to put together an I-D that includes provisions for supporting both mailing-lists and SMTP gateways without changing DKIM or SPF, or expecting ESP cooperation.  The work is to be done by those affected by DMARC and not rightfully the (ab)using ESP, acquiescing to the view might makes right.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 03 Apr 2015 08:22:30 +0900

> bunch of additional complexities begin to appear:

How about substituting s/U/T/?  Unpacking that rather obscure
expression, if you have a well-defined protocol (as opposed to, say,
the quoting convention for replies :-), the M*T*A (or spam-fighting
milter) could remove the parts signed only by 3rd parties, and add a
message/rfc822 subpart of the whole original message as an attachment
which the reader *could* look at, if they want to, in most M*U*As.
Really paranoid sites like A** and Y****! could just remove on
receipt.

 >   with users, which this community typically avoids like a terrible

Note that although this does rely on the MUA to havec certain
capabilities, most MUAs *do* have them, and I hope that users will
accept the inconvenience because they get the original message without
the third-party decorations.

I suspect this line of thought is beneficial only to MLs,
unfortunately.

---

From: [email-masked]
Date: Thu, 02 Apr 2015 16:49:42 -0700 (PDT)

>  DaveKIM-Signature: v=1; d=example.com; ...

Without getting into the desirability/utility of any sort of v2, I'll note that
the latter of these has one small advantage: It avoids any issues with broken
DKIM handlers that fail to correctly interpret the v= field.

Having said that, I think the version bump approach is a pretty significant
aesthetic win, especially if the change is, as noted below, to implement the
"must handle" tag.

And aesthetics in protocols do matter to some extent.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Apr 2015 17:35:25 -0700

On 4/1/2015 8:22 PM, John Levine wrote:
> verifier doesn't understand it, the verification fails. 

This handling of unrecognized tags is another change from existing DKIM:

     "3.6.1. Textual Representation
      ...
      The
      current valid tags are described below.  Other tags MAY be present
      and MUST be ignored by any implementation that does not understand
      them."

So receipt of a message signed in the new form will likely produce an
incorrect signature validation, since

   (1) the new tag's semantics won't be applied and

   (2) the new rule for unrecognized tags won't be applied.

d/

---

From: "John R Levine" <[email-masked]>
Date: 2 Apr 2015 21:25:58 -0400

> incorrect signature validation, ...

I wondered about that, too, so before I proposed a version bump, I took a 
look at the code that people use:

* Murray's opendkim C library: checks that the version is 0.5 or 1, 
fails otherwise.  That's the code in the milters that sendmail and postfix 
use, and I believe it's the library that everyone else with custom C code 
(including me) uses or adapts.  It replaces the older libdkim.

* Jason Long's perl Mail::DKIM: checks that the version is 0.5 or 1, will 
accept no v= at all for backward compatibility with DK but not other v= 
values.  This is what spamassassin uses.

* Scott K's dkimpy: checks that the version is 0.5 or 1.

A version bump appears unlikely to produce an incorrect signature 
validation unless there are other libraries in active use that ignored the 
spec that says to check the version number.

I suppose I could try sending v=2 signatures to my Yahoo and Gmail and 
Hotmail accounts to see what their trace headers say, but I'd be pretty 
surprised if they got it wrong.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Apr 2015 20:13:22 -0700

On Thu, Apr 2, 2015 at 6:25 PM, John R Levine <[email-masked]> wrote:

> * Murray's opendkim C library: checks that the version is 0.5 or 1, fails
> otherwise.  That's the code in the milters that sendmail and postfix use,
> and I believe it's the library that everyone else with custom C code

It won't accept 0.5 unless configured to do so, and that's off by default.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Apr 2015 14:40:12 -0400

On 4/2/2015 9:25 PM, John R Levine wrote:
> I wondered about that, too, so before I proposed a version bump, I
> took a look at the code that people use:
>
> fails otherwise.  That's the code in the milters that sendmail and
> postfix use, and I believe it's the library that everyone else with
> custom C code (including me) uses or adapts.  It replaces the older
> libdkim.

At least 8-10 years ago, it wasn't the library "everyone else" used. 
It wasn't quite portable to Windows (without changes).  It might be 
different today.  Alt-N's open source DKIM/ADSP library was a pure 
C/C++ portable package and it was used.  In this API, if "v=" exist, 
it checks for the string match of either:

    "1"
    "0.5"
    "0.4"
    "0.3"
    "0.2"

and returns a DKIM_SIG_VERSION_02_PLUS version otherwise 
DKIM_STAT_INCOMPAT. If "v=" did not exist, it returns a 
DKIM_SIG_VERSION_PRE_02 version.   None of this was made
optional to operators.  So a "version bump"  would return 
DKIM_STAT_INCOMPAT (unknown version).

-- 
HLS

---

From: Brandon Long <[email-masked]>
Date: Fri, 3 Apr 2015 15:48:15 -0700

Looks like we require v to exist and be either 1 or DKIM1, otherwise you'll
get a "bad format" or "bad version" in the AuthRes header.  Wonder how old
the DKIM1 is and whether we should remove that now...

Brandon

On Fri, Apr 3, 2015 at 11:40 AM, Hector Santos <[email-masked]> wrote:

> At least 8-10 years ago, it wasn't the library "everyone else" used. It
> wasn't quite portable to Windows (without changes).  It might be different
> today.  Alt-N's open source DKIM/ADSP library was a pure C/C++ portable
> package and it was used.  In this API, if "v=" exist, it checks for the
> string match of either:
>
>    "1"
>    "0.5"
>    "0.4"
>    "0.3"
>    "0.2"
>

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Fri, 03 Apr 2015 16:07:52 -0700

>>
>> * Murray's opendkim C library... the code in the milters that 
>> sendmail and postfix use, and I believe it's the library that 
>> everyone else with custom C code (including me) uses or adapts. It 
>> replaces the older libdkim.
>
> ...  Alt-N's open source DKIM/ADSP library was a pure C/C++ portable 
> package and it was used.  In this API, if "v=" exist, it checks for 
> the string match of either:
>
>    "1"
>    "0.5"
>    "0.4"
>    "0.3"
>    "0.2"

Dell also uses the Alt-N library (which I think is the same thing as 
"libdkim").

<csg>

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2015 02:42:29 -0000

In article <CABa8R6ujfHtRMC-Z11XiOto6WTfciXsFEKCGftOgHp=[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-

The DNS key record has to say v=DKIM1 while the signature says v=1

In answer to someone else's question, libdkim is inded the Alt-N
library which as far as I can tell hasn't been touched since 2008.
It still seems to work OK, and it checks the v= in the signature
to be "1" or some old 0.x test versions.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Apr 2015 21:18:23 -0700

> to be "1" or some old 0.x test versions.

Unfortunately the dkim-milter package (the predecessor to OpenDKIM) also
called its library "libdkim".

-MSK

---

From: Steven M Jones <[email-masked]>
Date: Mon, 06 Apr 2015 13:48:07 -0700

> dmarc.org [3] and the fact that this 'new' dmarc.org has only two

While the change to the organization is significant - for instance,
there is now a formal organization - there was actually not as
significant a change in support as you seem to be implying.

But with a formal organization replacing the loose collection of
cooperating companies, the term "sponsor" takes on a different - or at
least an additional - meaning. There are in fact three more founding
sponsors whose logos have not made it to that page for purely
administrative reasons. However DMARC.org continues to be advised by and
collaborate with most of the members of the preceding group, and other
organizations not part of that original group.

> [3] http://dmarc.org/about/

--Steve.

---

From: Franck Martin <[email-masked]>
Date: Tue, 28 Apr 2015 12:10:10 -0500 (CDT)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Wednesday, April 1, 2015 11:11:14 AM
> Has anyone looked at my double signing draft?  

Added in dmarc-interoperability