Subject: Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

From: [email-masked]
Date: Mon, 14 Nov 2016 05:36:33 -0800 (PST)

Let's break this down. If we're going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make:

(1) Whether or not to

    (a) Enumerate the recipients, or some representation of them, outside the
        DKIM hash, and sign that, or

    (b) Include the recipients, or some representation of them, under the
        DKIM hash only and don't expose them otherwise.

(2) Whether we enumerate recipients as:

    (a) Cleartext
    (b) Hashes
    (c) Encrypted form
    (d) Some combination of forms

    Note that (2)(b)-(d) are still choices even in the case of (1)(b).

(3) Whether or not the recipient check is an (a) mandatory or (b) optional part
    of the validation operation. (If you change what's signed in some way it's
    effectively mandatory, if you add a header containing either the hash of the
    recipients or a representation of the recipients and include it in
    the DKIM signature in the normal way it's optional.)

Now, in regards (1), I have to say I regard (1)(b) as a complete nonstarter,
for all the reasons previously given. The complete lack of control the sender
has over how recipient lists get split along the way has the potential to cause
all sorts of subtle failures. And given past behavior I don't trust senders
using this feature to use mitigations like single recipient messages when
necessary. In fact I skeptical most senders will even understand the issues in
play well enough to do the right thing.

I also categorically reject arguments along the lines of "this problem only
happens outside the intended use cases for this capability so we don't need to
worry about it". Given the way DMARC has deployed it would be utter folly to
base our design decisions on limited use case claims.

This is especially true since this mechanism can be employed, albeit in a crude
way, to try and prevent people from forwarding messages the message sender
doesn't want them to forward. And I absolutely can see people noticing this
capability and trying to use it.

In fact given the history here it's going to be seriously tempting to view
(1)(b) as yet another attack on existing email infrastructure, with all that
implies.

I'll also note that the implicit claim that the (1)(b)/(2)(a) combination
avoids exposing recipient information is in fact false. A simple
counterexample would be a message to a single Bcc: recipient in addition to the
whoever is listed in the various headers. If I receive such a message I can
simply perform the DKIM operation on the recipients listed in the headers, and
if it doesn't match I know there's a Bcc:. I then try inserting possible Bcc:
recipients into the list until I get a match. And in many cases I'll have a
pretty good idea what addresses to try, so in those cases this attack will be
many, many, many orders of magnitude more effective than brute force.

I believe this last point makes (2)(a) a nonstarter regardless of how (1) is
answered. 

As for whether or not (2)(b) or (2)(c) makes the most sense, the fact that in
many cases a recipient can come up with a list of likely addresses to try as
noted above is a really serious problem for any hash-based scheme. I'm not
exactly wild about the idea of all the public key operations (2)(c) calls for,
but I'm even less enthusiastic about adding to the reicpient leakage problem in
any way.

As for (2)(d), I see little point in using it in conjuction with (2)(b) - it's
much simpler to hash them all and be done with it. The combination of (2)(c)
and (2)(d), however, has the potential of eliminating some/most of the
public key overhead. (Another variation would be to use (2)(c) when
a public key is available and (2)(b) when it isn't.)

And that brings us to (3). It's important to note that making recipient checks
a mandatory part of validation doesn't make enforcement mandatory - a reciever
can simply detect and ignore DKIM signatures that require recipient checks.

The capability optional recipient validation provides is that a receiver has
the option of using the signature in the usual way. (That, and backwards
compatibility.)

Finally, I note that there is in fact a (0):

(0) This scheme can be applied to

    (a) Any message
    (b) Single recipient.

Requiring separate copies for each recipient in order to cover the recipient
with a signature renders (1) and (2) moot. In fact this scheme is so simple
that it merits serious consideration.

The big problem I see with (0)(b) is the overhead it imposes downstream. But as
I noted previously, so many messages are already sent separately to different
recipients it's unclear to what extent this is a factor.

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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 14 Nov 2016 23:41:16 +0100

On 14-11-16 14:00, John R Levine wrote:
> [ resent with a reasonably correct date header ]
>
> I can write this up as a draft if people think it's interesting.
>
> Murray's draft puts the envelope recipients into the DKIM hash, which
> means that the message sent to multiple MTAs be signed separately for
> each target MTA.
>
> My version puts the recipient addresses into the DKIM-Signature header
> in an r= tag, separated by colons, using the usual quoted printable
> to quote colons, semicolons or any other inconvenient characters, e.g.,
>
> DKIM-Signature: v=1; ... r=[email-masked]:[email-masked]; ...

At the time SenderID was proposed, back in 2004 or something, the act of 
propagating header information into the transport stream was seen by 
many as a layering violation. The proposal of Murray and Johns suggested 
kludge alternative do the reverse: propagating envelope information to 
the header. In my view this is, again, a layering violation. The 
downside of crossing layer borders is that transport and header 
information are (too) tightly coupled, which makes that the flexibility 
of the original mail design (RFC821/RFC822)  is lost.

Another aspect, in addition to (3) in Ned's answer, is that changing the 
way DKIM works brings a huge risk with it, now that DMARC is widely 
deployed and DMARC heavily relies on DKIM. So any change that is 
proposed for DKIM must have zero impact on the DKIM verification that is 
used by DMARC implementations currently in use.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Nov 2016 07:51:01 +0900

Hi Rolf,

On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld <
[email-masked]> wrote:

> propagating header information into the transport stream was seen by many
> as a layering violation. The proposal of Murray and Johns suggested kludge
> alternative do the reverse: propagating envelope information to the header.
> In my view this is, again, a layering violation. The downside of crossing
> layer borders is that transport and header information are (too) tightly
> coupled, which makes that the flexibility of the original mail design
> (RFC821/RFC822)  is lost.
>

There's obviously some truth to this, but there's also truth to the fact
that humans, the ones this community seeks to serve, routinely cross layers
in both directions whether or not we do so in protocols.  End user
education has never been a viable answer to protocol limitations as far as
I'm aware, much as we all wish it were so.

I'm willing to hold my nose -- a little -- at a reach across a layer
boundary if there's potentially a large win.  Whether this proposal or some
variant of it qualifies is why I brought the question to this group.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Nov 2016 08:07:38 +0900

On Mon, Nov 14, 2016 at 10:36 PM, <[email-masked]> wrote:

> [...]

That's a pretty excellent summary.  A couple of points:

I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being
the ideal choices.  Is that correct?  If so, we would just need to
determine the algorithm for generating the signed content that would be
included in the augmented signature.  If we do something like the random
salt suggestion, is this sufficient?

- pick a random string S of length L using only printable ASCII characters
(I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and
express the result in base64 string R
- include R in a new "er" (envelope recipient) tag and the salt S in an
"rs" (recipient salt) tag

This is not reversible so nothing is leaked, but as we've all conceded by
now it's not hard to attack this to recover the hashed address especially
since one might have good guesses as to what that address would be.

I can't see the point of actually encrypting the hashed content, because
anybody can decrypt it with the public key.

What am I missing?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Nov 2016 22:31:13 +0900

On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin <[email-masked]>
wrote:

> 15.11.2016 2:07, Murray S. Kucherawy пишет:
>
> There is no need to reverse if you know e-mail address. Alice can check
> Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail and
> check if he is in 'er'.
>

Yes.  I wasn't identifying "not reversible" as a shortcoming, but rather as
a benefit.

-MSK

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 15 Nov 2016 16:31:43 +0000

On Tue, Nov 15, 2016 at 08:07:38AM +0900, Murray S. Kucherawy wrote:
> This is not reversible so nothing is leaked, but as we've all conceded by now
> it's not hard to attack this to recover the hashed address especially since one
> might have good guesses as to what that address would be.

I can think of scenarios where the mere fact that someone is BCC'd is
something you don't want to be known.

If we're concerned about BCC - and I kind of think we should be - then
how about telling senders who care to include all To:, Cc:, Resent-To:
etc. headers to the DKIM signature and to create a separate copy, with a
separate signature, for each BCC'd recipient, which includes a Bcc:
header which is also signed.

DMARC may be a good way for senders to show they care, in other words
for a domain owner to say: if you receive an email signed by us and the
receipient is not in one of the following headers, or that header isn't
signed, the message was relayed or replayed.

Martijn.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 10:45:52 +0900

There's been a lot of great feedback here.  I just cranked out an update
based on the discussion so far:

https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01

I forgot to update the title of Section 3, but other than that I think I
captured what's been discussed.  Please let me know what I've missed.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Nov 2016 20:12:31 -0600

Note: Not cc'ing the DMARC list as this is a DKIM only draft.

Given the discussions about twice ranging implications of a change like this (the end of email where RCPT TO changes in transit to start), the document needs far more discussion regarding the impact on the current email architecture before it can be considered in any way complete.

As much as I appreciate having my input acknowledged, please remove me from the acknowledgement section.  If this proposal is going to go forward, I don't want my name on it anywhere.

Scott K

On November 15, 2016 7:45:52 PM CST, "Murray S. Kucherawy" <[email-masked]> wrote:
>------------------------------------------------------------------------
>
>dmarc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 11:26:49 +0900

On Wed, Nov 16, 2016 at 10:56 AM, John R Levine <[email-masked]> wrote:

> How come rh= has one hash instead of several?  You can put all the
> addresses in the To: and Cc: headers in one header without leaking, then do
> separate single hash if there are bcc's.

I found Ned's comments about signing only individual recipients convincing,
so that's the direction I took in this revision.  It's hardly final; by all
means, let's hash it out.

So you want to pack all the envelope recipients into, say, a
colon-separated list in "rh=", and then just confirm each envelope
recipient is represented in that list?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 11:28:08 +0900

On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink <[email-masked]>
wrote:

> Large email receivers forward tons of email. This proposal causes email
> from DMARC-passing messages to be incapable of forwarding. As a large email
> receiver who gets tons of complaints about breakage of DKIM signatures on
> forwarded messages which causes DMARC failures [1], this proposal is not
> all that appealing.
>

Version 01 is purely incremental, meaning you can just ignore the new tags
if you're more worried about breakage of forwarding than the attack it's
trying to address.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 13:38:59 +0900

On Wed, Nov 16, 2016 at 1:05 PM, John R Levine <[email-masked]> wrote:

>
> So far this exercise has mostly served to persuade me that putting
> envelope info in the DKIM signature is a bad idea, and our advice to people
> who have problems with recipients remailing spam they've signed remains
> "don't do that."
>
>
I agree, and I'm certainly fine with saying that more forcefully than the
text that's currently there.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 16 Nov 2016 18:44:41 +0900

> if you're more worried about breakage of forwarding than the attack it's

Ah, I'd missed that you took out the magic hash goop.  If it's optional, 
it's still a bad idea, but it breaks a lot less stuff.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Nov 2016 11:57:16 +0100

On Wed 16/Nov/2016 03:28:08 +0100 Murray S. Kucherawy wrote:
> On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink wrote:
>
>> from DMARC-passing messages to be incapable of forwarding. As a large
>> email receiver who gets tons of complaints about breakage of DKIM
>> signatures on forwarded messages which causes DMARC failures [1], this
>> proposal is not all that appealing.
>

That way it will stay dormant until someone gets hurt and has to activate it, 
at which time it may cause more damage than improvement.  A loose cannon.  I'd 
keep it in its own header field [Ned's (1)(a)], so as to avoid the risk Rolf 
points out.

Besides forwarding, use of this method worsens mailing lists breakage further, 
which makes it totally out of scope for dmarc-ietf.  At this point, I follow 
Dave's directive and remove that Cc:.

Finally, if you stick to one recipient per message, why do you rack your brains 
about encryption?  I suggest adding a Disclosed-BCC: header field with the 
recipient address in the same 5322.address-list cleartext format as the other 
address fields, and sign it FWIW.  It won't break more privacy than 
Delivered-To: does.

Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 22:00:26 +0900

On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely <[email-masked]> wrote:

> That way it will stay dormant until someone gets hurt and has to activate
> it, at which time it may cause more damage than improvement.  A loose
> cannon.  I'd keep it in its own header field [Ned's (1)(a)], so as to avoid
> the risk Rolf points out.
>

The document makes that risk clear, or so I thought.  I'd be happy to get
proposals for stronger language if needed.

Why does it need its own header field?  It's harmless expressed as tags in
the existing header field since they're ignored by verifiers that don't
know the new tags.

> Besides forwarding, use of this method worsens mailing lists breakage
> further, which makes it totally out of scope for dmarc-ietf.  At this
> point, I follow Dave's directive and remove that Cc:.
>

Yes, I agree.

> Finally, if you stick to one recipient per message, why do you rack your
> brains about encryption?  I suggest adding a Disclosed-BCC: header field
> with the recipient address in the same 5322.address-list cleartext format
> as the other address fields, and sign it FWIW.  It won't break more privacy
> than Delivered-To: does.
>

I don't follow.  There's no additional encryption going on here.

Adding a "Disclosed-BCC" field guarantees disclosure, rather than only
disclosing if the MDA adds a Delivered-To.  I don't think we should make
that worse.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 22:03:48 +0900

(dropping DMARC again)

On Wed, Nov 16, 2016 at 9:51 PM, Michael Storz <[email-masked]> wrote:

> Version 01 is purely incremental, meaning you can just ignore the new
>> tags if you're more worried about breakage of forwarding than the
>> attack it's trying to address.
>>
>
> Optional for the sender, yes, but not for the receiving MTA. If the sender
> decides to use the new Anti-Replay-DKIM-Signature and has published a DMARC
> policy with reject or quarantine, then this policy is implicitly extended
> with

> "ooh, and btw reject/quarantine ALL indirect emails, even if a normal DKIM
> signature could be verified"
>

That's not correct.  The verifying MTA, if it doesn't know the new tags, is
unaffected by the new tags because RFC6376 directs the verifier to ignore
them.  It's as if they weren't there.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Nov 2016 08:13:49 -0500

On 11/16/2016 8:03 AM, Murray S. Kucherawy wrote:
>
>
> That's not correct.  The verifying MTA, if it doesn't know the new
> tags, is unaffected by the new tags because RFC6376 directs the
> verifier to ignore them.  It's as if they weren't there.
>

Do you have any data with unknown tag recordings adding any 
(erroneous) negative scoring or suspicion on mail?

For example, there is a DMARC wizard out there, give it a domain and 
it evaluates/displays the DMARC record.  It will report unknown tags 
and I already seen one case where this adds unsureness to the situation.

-- 
HLS

---

From: Michael Storz <[email-masked]>
Date: Wed, 16 Nov 2016 15:50:08 +0100

Am 2016-11-16 14:03, schrieb Murray S. Kucherawy:
>> Optional for the sender, yes, but not for the receiving MTA. If the
>> sender decides to use the new Anti-Replay-DKIM-Signature and has
>> published a DMARC policy with reject or quarantine, then this policy
>> is implicitly extended with
> 
>> "ooh, and btw reject/quarantine ALL indirect emails, even if a
>> normal DKIM signature could be verified"
> 

Ok, I see you have removed the hashing of the recipient together with 
the email itself. But how do you prevent a replay attack, if the new tag 
is not bound to the email and signed with the DKIM-key (that's how I 
read 4.1.4)? The spammer could remove the tag or provide his own tag 
with the new recipient before resending the email.

Michael

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Nov 2016 19:47:34 +0100

On Wed 16/Nov/2016 14:00:26 +0100 Murray S. Kucherawy wrote:
>> cannon.
> The document makes that risk clear, or so I thought.

You mean Section 5?

> I don't follow.  There's no additional encryption going on here.

I mean the SHA transformation.  Cleartext is obviously easier to understand and 
debug.

> disclosing if the MDA adds a Delivered-To.  I don't think we should make

So long as you disclose it to the very recipient, there is no worry.  NDNs 
customarily report SMTP chit-chat in cleartext, betraying users who attempt to 
hide their real address behind a dot-forward.  Log files are plenty of envelope 
citations.  Received: fields feature a FOR clause which is not deprecated for 
single recipient messages.  We're not worsening anything.

Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2016 05:00:14 +0900

On Wed, Nov 16, 2016 at 11:50 PM, Michael Storz <[email-masked]>
wrote:

>
> Ok, I see you have removed the hashing of the recipient together with the
> email itself. But how do you prevent a replay attack, if the new tag is not
> bound to the email and signed with the DKIM-key (that's how I read 4.1.4)?
> The spammer could remove the tag or provide his own tag with the new
> recipient before resending the email.
>

The signature signs itself, so removing or changing the tag invalidates the
signature.  Have a look at RFC6376, Sections 3.5 and 5.1.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2016 05:12:45 +0900

>> The document makes that risk clear, or so I thought.

Yes.

> I mean the SHA transformation.  Cleartext is obviously easier to
> understand and debug.

I wouldn't say a salted hash qualifies as "racking my brains".  The idea is
to make it difficult to see who the envelope recipient is simply by
looking.  A one-way transformation forces an interloper to make guesses and
try to confirm, and the salt guarantees that your email address does not
always hash to the same thing.  It's not perfect security by any means, but
it's a cheap way to limit what gets leaked.  This too is spelled out in
Section 7.

> customarily report SMTP chit-chat in cleartext, betraying users who attempt
> to hide their real address behind a dot-forward.  Log files are plenty of
> envelope citations.  Received: fields feature a FOR clause which is not
> deprecated for single recipient messages.  We're not worsening anything.
>

If you hand me a printed copy of a message without the envelope, and the
Received didn't use the (non-standard) "for" clause, I cannot be certain it
was delivered to whatever the To and Cc say, if they're even present.  It
may have gone only to an envelope recipient that isn't visible.  That is,
if there was a Bcc, it's not revealed to me.  If you insist on using "for"
or "Disclosed-Bcc", that information is guaranteed to be exposed, and I can
see who that secret recipient was.

By contrast, including these tags at most reveals to me that there was a
Bcc, but I have to do some complex (though these days, cheap) math to guess
whether a specific address was in there.  If I never make the correct
guess, the secret is never revealed.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2016 05:57:08 +0900

On Thu, Nov 17, 2016 at 3:09 AM, Terry Zink <[email-masked]>
wrote:

> > This means ARC will be needed not only for mailing lists which modify
> the header or
> > body of an email, but for EVERY mailing list and EVERY forwarded email
> or EVERYTIME
> > the recipient has been modified and the email leaves the ADMD boundary.
> From a
> > DMARC point of view DKIM will not be needed anymore because it has now
> the same
> > function as SPF - verifiying the origin of direct emails - and SPF is
> easier to implement
> > for most administrators.
>
> +1.
>
> It basically (almost) turns DKIM into SPF. That's not that appealing a
> solution.

Yep, it does.  And as we've already said on this thread, "Don't do that"
(i.e., don't sign spam in the first place) is far and away the preferred
solution, but it does happen resulting in increased reputation-enhanced
spam delivery to inboxes.  So we have a choice now between not doing
something like this which enables the attack described in the document to
continue, or doing something like this and making DMARC have to go through
some kind of unpleasant permutation.

It's funny you should mention ARC, because this was first raised on the
mailing list where ARC is developed, and then discussed further at MAAWG
this fall, and then brought to us to brainstorm on a solution.  So far,
this is where we've landed as being the least damaging thing to do when
"don't sign spam in the first place" is rejected as a solution.

Maybe we should take this back to the MAAWG technical discussions list.
I'll do that later today.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 17 Nov 2016 11:28:10 +0100

>>> The document makes that risk clear, or so I thought.

Well, if its title were *Incompatibility with Current Infrastructure*, I would 
agree there is a statement on the risk of disrupting how DKIM works.

>>>> brains about encryption?  I suggest adding a Disclosed-BCC:
>>>

"To make guesses" is not the specified implementation.  Section 4.2 says 
envelop recipient must match exactly.  This requirement not only forces 
single-recipient mode, but also rules out verifiers which run after acceptance 
or after alias expansion.  An incredibly narrow scope, overall.

If instead you really allow some guessing, as mentioned in Section 7, you may 
rehabilitate a range of verifiers, but undoubtedly do so at the cost of full 
scale brains racking.

> was delivered to whatever the To and Cc say, if they're even present.

I don't think I'm with you.  You seem to mean you don't know if, say, Terry 
actually received a copy of this.  For example, one might arrange social 
engineering by adding CC:'s to your boss, the press, the police, et cetera, 
none of which corresponds to the envelope.  Is that concern part of the problem 
at hand?

> It may have gone only to an envelope recipient that isn't visible.  That
> is, if there was a Bcc, it's not revealed to me.  If you insist on using
> "for" or "Disclosed-Bcc", that information is guaranteed to be exposed, and
> I can see who that secret recipient was.

Invisible recipients may come from BCCs or other sources.  When you get the 
message, you may want to know why it was delivered to you, and, yes, "for" or 
"Disclosed-Bcc" let you know that.  Why should that info be kept secret?

> guess, the secret is never revealed.

I fail to see why that would be an advantage:

The address is likely shorter than its hash.

In general, it would be nice to have a standard means to tell recipients on 
what grounds a message was delivered to their mailboxes.  For example, was it a 
role address or a personal one?  If the message body is ambiguous (e.g. short 
messages) knowing the original recipient address may help.

In the scenario you are proposing, only mailbox providers know the envelope, 
and can verify if that was what the sending domain signed.  Final recipients 
--the actual subjects-- cannot access that info.  That picture looks unfair. 
Indeed, in some countries providers may seem to be legally bound to reveal the 
envelope address upon subject request (IANAL).

Ale

---

From: Michael Storz <[email-masked]>
Date: Thu, 17 Nov 2016 13:51:32 +0100

Am 2016-11-16 21:00, schrieb Murray S. Kucherawy:
>> Ok, I see you have removed the hashing of the recipient together
>> with the email itself. But how do you prevent a replay attack, if
>> the new tag is not bound to the email and signed with the DKIM-key
>> (that's how I read 4.1.4)? The spammer could remove the tag or
>> provide his own tag with the new recipient before resending the
>> email.
> 
> The signature signs itself, so removing or changing the tag
> invalidates the signature.  Have a look at RFC6376, Sections 3.5 and
> 5.1.
> 
> -MSK

Thanks, I see. That means the recipient is bound to the message and an 
attacker cannot delete or change the new tags. Great solution, I like 
it, though I do not like the consequences when this extension will go 
into production.

Michael

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2016 22:53:43 +0900

On Thu, Nov 17, 2016 at 7:28 PM, Alessandro Vesely <[email-masked]> wrote:

>
> Yes.
>>
>
> Well, if its title were *Incompatibility with Current Infrastructure*, I
> would agree there is a statement on the risk of disrupting how DKIM works.
>

That section talks about some things that are compatible (ignored tags are
harmless, for example) and some that are not.

> envelop recipient must match exactly.
>

I'm completely confused about the flow of the conversation here.  The
guessing has to be done by an attacker, not by the true verifier.  See
below.

> This requirement not only forces single-recipient mode, but also rules out
> verifiers which run after acceptance or after alias expansion.  An
> incredibly narrow scope, overall.
>

Correct.  The -00 version of the document had better text about it that got
lost somehow.  I'll put it or something equivalent back in a future version.

> If instead you really allow some guessing, as mentioned in Section 7, you
> may rehabilitate a range of verifiers, but undoubtedly do so at the cost of
> full scale brains racking.

A verifier doesn't have to guess.  It has a recipient in hand that either
passes the test or does not.

To illustrate: The value of "rh" is base64(rs + rcpt) and the proposal
asserts that both the signer and the verifier have to arrive at the same
value.  The actual signer and verifier have "rs" and "rcpt", the two
inputs, so they get the same result for "rh"; there is no guessing.  An
attacker, however, has an "rh" and "rs" value, but no "rcpt".  It has to
guess.  The weakness is that the mechanism allows for such guesses to be
confirmed when they're right, and it's often the case that there's
information available to narrow the scope of such guessing.  But I think
the document already discusses that.

> I don't think I'm with you.  You seem to mean you don't know if, say,
> Terry actually received a copy of this.

Correct, I don't.  In fact, given a printed copy of this message, I don't
know who actually received it, as I no longer have the envelope.  The To
and Cc don't have to have any relationship with the delivery envelope at
all.

> For example, one might arrange social engineering by adding CC:'s to your
> boss, the press, the police, et cetera, none of which corresponds to the
> envelope.  Is that concern part of the problem at hand?
>

I wouldn't call it a concern, but yes, it explains this aspect of the
proposal.

> Invisible recipients may come from BCCs or other sources.  When you get
> the message, you may want to know why it was delivered to you, and, yes,
> "for" or "Disclosed-Bcc" let you know that.  Why should that info be kept
> secret?
>

Exactly for the reason I gave: If you force a Bcc to be visible by sticking
it in a header field, and then print it, the "B" in "Bcc" is gone; the
secret recipient is fully revealed.  I don't know why that would be
desirable.

> The address is likely shorter than its hash.

Your logic is puzzling here.  I don't know about you, but I'm willing to
trade a few bytes to retain privacy.

> In general, it would be nice to have a standard means to tell recipients
> on what grounds a message was delivered to their mailboxes.  For example,
> was it a role address or a personal one?  If the message body is ambiguous
> (e.g. short messages) knowing the original recipient address may help.
>

That seems to be a goal wholly outside of the scope of this proposal.

> In the scenario you are proposing, only mailbox providers know the
> envelope, and can verify if that was what the sending domain signed.

Yes.

> Final recipients --the actual subjects-- cannot access that info.  That
> picture looks unfair. Indeed, in some countries providers may seem to be
> legally bound to reveal the envelope address upon subject request (IANAL).
>

Sic semper erat.

There is no standard that says the envelope must or even should be copied
into the header on delivery, nor is there a standard way to do so.  Why is
that suddenly something that needs fixing, either in general or in
particular with this proposal?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 17 Nov 2016 09:30:13 -0500

On 11/16/2016 1:09 PM, Terry Zink wrote:
>> This means ARC will be needed not only for mailing lists which modify the header or
>> body of an email, but for EVERY mailing list and EVERY forwarded email or EVERYTIME
>> the recipient has been modified and the email leaves the ADMD boundary. From a
>> DMARC point of view DKIM will not be needed anymore because it has now the same
>> function as SPF - verifiying the origin of direct emails - and SPF is easier to implement
>> for most administrators.
>
> +1.
>
> It basically (almost) turns DKIM into SPF. That's not that appealing a solution.

For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC 
or ARC for that matter since the receiver (at least ours) will never 
accept the payload anyway, i.e. it never gets to the SMTP "DATA" 
state.  SPF does not require you to accept the mail for the hard 
reject policy (-ALL).

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 17 Nov 2016 14:34:26 +0000

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Thursday, November 17, 2016 9:30 AM
> To: [email-masked]; Ietf Dkim
> Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-
> kucherawy-dmarc-rcpts
> 
> >> the header or body of an email, but for EVERY mailing list and EVERY
> >> forwarded email or EVERYTIME the recipient has been modified and the
> >> email leaves the ADMD boundary. From a DMARC point of view DKIM will
> >> not be needed anymore because it has now the same function as SPF -
> >> verifiying the origin of direct emails - and SPF is easier to implement for
> most administrators.
> >
> > +1.
> >
> For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or ARC
> for that matter since the receiver (at least ours) will never accept the payload
> anyway, i.e. it never gets to the SMTP "DATA"
> state.  SPF does not require you to accept the mail for the hard reject policy
> (-ALL).
> 

Hector, the reality is that most mailbox providers do not reject on SPF -all because so many senders don't understand what they are "saying" with -all and the mailbox providers are the ones who get the complaints about mail not getting delivered. THAT is reality.

Mike

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 17 Nov 2016 17:11:42 +0100

Hi, Murray,

On 16-11-16 02:45, Murray S. Kucherawy wrote:
> There's been a lot of great feedback here.  I just cranked out an 
> update based on the discussion so far:
>
> I forgot to update the title of Section 3, but other than that I think 
> I captured what's been discussed.  Please let me know what I've missed.

the intended status field is empty, but do you have some intended status 
in mind or not yet?

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Nov 2016 03:45:49 +0900

> the intended status field is empty, but do you have some intended status

All of the versions I can see at
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ show
"Standards Track" as the Intended Status field, meaning it would get
"Proposed Standard" on publication.  I think if we get more than one
operator interested in trying this, then that's the right thing.  If we get
no commitment, "Experimental" is fine, if we go ahead with it at all.

If you're talking about the "Intended RFC Status" in the datatracker, which
still says "(None)", that's not set by the document author; it's set by the
working group chair, sponsoring Area Director, or Independent Submission
editor once it formally enters one of the two possible processing streams.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Nov 2016 05:57:00 +0900

On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz <[email-masked]> wrote:

> attacker cannot delete or change the new tags. Great solution, I like it,
> though I do not like the consequences when this extension will go into
> production.
>
>
You may not need to worry about that.  We've reached a point where I think
we can legitimately say, "We took a serious look, and this is the best we
could come up with.  It has some pretty ugly side effects.  Are you sure
you can't just stop signing spam?"  And absent a compelling answer to that
question, there's no need to roll this out even as an experiment.

-MSK

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 17 Nov 2016 21:01:59 +0000

What Murray says makes sense. I don’t see the value of going forward with this approach given the negative impacts involved.

Mike

From: ietf-dkim [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Thursday, November 17, 2016 3:57 PM
To: Michael Storz
Cc: Ietf Dkim
Subject: Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz <[email-masked]<mailto:[email-masked]>> wrote:

Thanks, I see. That means the recipient is bound to the message and an attacker cannot delete or change the new tags. Great solution, I like it, though I do not like the consequences when this extension will go into production.

You may not need to worry about that.  We've reached a point where I think we can legitimately say, "We took a serious look, and this is the best we could come up with.  It has some pretty ugly side effects.  Are you sure you can't just stop signing spam?"  And absent a compelling answer to that question, there's no need to roll this out even as an experiment.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 17 Nov 2016 15:47:51 -0600

On November 17, 2016 2:57:00 PM CST, "Murray S. Kucherawy" <[email-masked]> wrote:
>it,

That's great to hear.

You might suggest (if it's someone that does DMARC p=reject) that if they can manage to stop signing reasonably likely (FSVO reasonable) spam they'll get roughly what the proposed protocol change would have provided for that mail without having to wait for the world to upgrade.  Direct mail would still pass DMARC due to SPF.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 17 Nov 2016 18:05:00 -0500

> Hector, the reality is that most mailbox providers do not reject on SPF -all because so many senders don't understand what they are "saying" with -all and the mailbox providers are the ones who get…

Is "MOST" 100%, 90%, 80%, 70%, 51%?  The fact is there are receivers 
that do reject on -ALL. Its doesn't matter if its 1%.  The specs has 
always allowed to be done and it is done.  That's the reality. All 
systems need to be ready to handle that situation.  The payload isn't 
even transferred. In the 13 years implementing it, I can't even recall 
one false positive. Another point is that many domains have switched 
their early SoftFail or Neutral setup to Hardfail for the primary 
purpose of rejection despite how a receiver will actually do 
rejection.  A good majority of high value domains are Hard Fails and 
have been for a number of years.  I just don't buy that the notion 
that senders don't know what they are doing.

In any case, my main point is that if you use SPF -ALL, you can bypass 
lots of unnecessary overhead processing in DKIM/DMARC or any related 
payload technology.

-- 
HLS

---

From: Michael Storz <[email-masked]>
Date: Fri, 18 Nov 2016 12:47:09 +0100

Am 2016-11-17 21:57, schrieb Murray S. Kucherawy:
>> Thanks, I see. That means the recipient is bound to the message and
>> an attacker cannot delete or change the new tags. Great solution, I
>> like it, though I do not like the consequences when this extension
>> will go into production.
> 
> You may not need to worry about that.  We've reached a point where I
> think we can legitimately say, "We took a serious look, and this is
> the best we could come up with.  It has some pretty ugly side effects.
>  Are you sure you can't just stop signing spam?"  And absent a
> compelling answer to that question, there's no need to roll this out
> even as an experiment.
> 
> -MSK

Thanks Murray. My concern was, that a change to DMARC would give people 
the possibility to switch this optional extension to a mandatory one 
which has dramatic consequences at the moment. And I agree this change 
to DMARC should not be done at least in the near future.

However, for the extension itself we should carefully evaluate the 
positive and negative aspects.

Normal DKIM-Signatures give us a way to check if the body and/or header 
of an email has been changed on the way from the signer to the verifier. 
The new extension extends this to the recipients of the email. A change 
means the email was either relayed (now indirect mail) or replayed. I 
think this is a new valuable information for an anti-spam-system. 
However, we have not discussed how this gets propagated from the 
verifier to the consumer of the information.

The negative side of the proposal is the requirement to split all 
multi-recipient-emails to single-recipient-emails, which is a show 
stopper for me. But I don't think this requirement is needed. I would 
allow a list of recipients and have a paragraph which states:

===
Every compliant implementation of this extension MUST check if the 
signing of the message as is would result in the leakage of hidden BCC 
recipients. The check has to be done in the following way:

- Collect the set of visible recipients from the header fields

   * From
   * Sender
   * Reply-To
   * To
   * CC
   * Resent-From
   * Resent-Sender
   * Resent-To
   * Resent-CC

- For each address from the set of envelope recipients check if the 
address is included in the set of visible recipients.

   If not, then either

   * refuse to sign with this extension or
   * split the message and sign and send a single-recipient-copy of the 
message with this recipient
===

If the submission MTA already enforces the handling of bcc recipients as 
described in https://tools.ietf.org/search/rfc5322#section-3.6.3 the 
signing can always be done.

Depending on an underlying policy from the administrator the "refuse to 
sign with this extension" could mean

- to sign without the extension
- wave the message through without signing
- to reject the message with an error like "Configuration error: DKIM 
signing this message would leak BCC recipients"

This check and the resulting split action is RFC 5322 compliant. However 
it would need to use the second variant of the bcc handling with the 
single-bcc-recipient-email.

In this multi-recipient scenario the hashing of the recipient makes 
sense. It protects against passive attacks (just looking at the header) 
but not against active attacks.

How about this?

Michael

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Nov 2016 13:53:34 -0800

On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz <[email-masked]> wrote:

> Normal DKIM-Signatures give us a way to check if the body and/or header of
> an email has been changed on the way from the signer to the verifier. The
> new extension extends this to the recipients of the email. A change means
> the email was either relayed (now indirect mail) or replayed. I think this
> is a new valuable information for an anti-spam-system. However, we have not
> discussed how this gets propagated from the verifier to the consumer of the
> information.
>

That's certainly possible to do if it's useful.  The pseudo-API described
by RFC6376 is vague; it just says the signature has to fail.  Whatever
reporting mechanism you want to provide in an actual implementation is fine
as long as it complies just to that.  A specific error code, or sub-code (a
la enhanced status codes) is certainly a valid choice.  OpenDKIM has a
large number of them.

> multi-recipient-emails to single-recipient-emails, which is a show stopper
> for me.

That's curious; why?

> But I don't think this requirement is needed. I would allow a list of
> recipients and have a paragraph which states:

> ===
> Every compliant implementation of this extension MUST check if the signing
> of the message as is would result in the leakage of hidden BCC recipients.
> The check has to be done in the following way:
>

We discussed the idea of tying it directly to To and Cc.  The downside of
doing so is that participating DKIM implementations would have to know the
syntax and semantics of RFC5322 header fields; right now it needs only very
basic syntax information about them, just enough to run canonicalization.
It adds a whole lot of code complexity we'd rather avoid.  On top of that,
if someone were to later register some other sender or recipient header
field that should be included in this list, we'd have to update everything
on the DKIM side by updating this list.

Simplicity is very desirable here, as is reaching across the layer boundary
as little as possible.

===
> signing can always be done.

This sort of thing might work if you also specify the way both ends will
process this symmetrically.  Any ambiguity will result in interoperability
problems.

> signing this message would leak BCC recipients"

These are purely implementation policy choices.  At best a specification
like this one would lay them out as options in a non-normative way.

> In this multi-recipient scenario the hashing of the recipient makes sense.
> It protects against passive attacks (just looking at the header) but not
> against active attacks.
>
> How about this?

It's worth considering further if we were to become convinced that this is
a problem that needs to be solved in the form of changes to DKIM.  Right
now I think we should wait for operators to explain why going down any of
these paths is the best option.  My main worry is that it seems to invite a
lot of complexity in code and either solution would introduce a lot of
complexity into the problem space, possibly more than they really would
solve.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 19 Nov 2016 09:22:10 -0500

> multi-recipient-emails to single-recipient-emails, which is a show stopper 

I'm with Murray -- why is this a problem?  Single recipient has been the 
de-facto standard for years, and unless you are extremely bandwidth 
constrained, it's faster.

> recipients and have a paragraph which states ...

See previous discussion.  We rejected multi-recipient signatures because 
of the bcc recipipient leakage.

Regards,

---

From: Brandon Long <[email-masked]>
Date: Mon, 21 Nov 2016 18:15:55 -0800

Also realize that this isn't "Gmail shouldn't sign spam", it's everyone who
normally has a good reputation needs to not sign spam, this is a way to
steal reputation from any service allowing you to choose your own message,
and can be used against any mail receiver.

That said, I think this proposal mostly duplicates spf with some small
benefit, but one can combine the spf and dkim signals to try to combat this
issue without introducing a new standard.  Forwarding will take the worst
hit in false positives, but things like arc may help with that issue
separately.

Brandon

---

From: "John R. Levine" <[email-masked]>
Date: 21 Nov 2016 21:30:49 -0500

> and can be used against any mail receiver.

Just wondering, roughly when would you use the no-forward flag?  I hope 
you wouldn't use it on everything, since that would make DMARC have far 
worse effects on legit mail than the current mailing list issues.

Regards,

---

From: Brandon Long <[email-masked]>
Date: Mon, 21 Nov 2016 19:16:35 -0800

On Nov 21, 2016 6:30 PM, "John R. Levine" <[email-masked]> wrote:

> and can be used against any mail receiver.

Just wondering, roughly when would you use the no-forward flag?  I hope you
wouldn't use it on everything, since that would make DMARC have far worse
effects on legit mail than the current mailing list issues.

No, I'm not recommending -all.  I'm saying that this increases the value of
an spf pass in your spam filtering.  Ie, an spf pass and a dkim pass is
worth more in your scoring than a dkim pass and spf fail.

Which is obviously a short hand for how it's actually used, but that's the
general form of working this attack.

A dkim with hidden knowledge of recipient will survive forwarding with some
amount of work on sharing knowledge of forwarding paths, but without that
is no better than spf.  ARC would allow forwarding spf pass info, which
would be useful, but isn't available.

Brandon

---

From: Michael Storz <[email-masked]>
Date: Tue, 22 Nov 2016 16:45:55 +0100

Am 2016-11-18 22:53, schrieb Murray S. Kucherawy:
>> Normal DKIM-Signatures give us a way to check if the body and/or
>> header of an email has been changed on the way from the signer to
>> the verifier. The new extension extends this to the recipients of
>> the email. A change means the email was either relayed (now indirect
>> mail) or replayed. I think this is a new valuable information for an
>> anti-spam-system. However, we have not discussed how this gets
>> propagated from the verifier to the consumer of the information.
> 
> That's certainly possible to do if it's useful.  The pseudo-API
> described by RFC6376 is vague; it just says the signature has to fail.
>  Whatever reporting mechanism you want to provide in an actual
> implementation is fine as long as it complies just to that.  A
> specific error code, or sub-code (a la enhanced status codes) is
> certainly a valid choice.  OpenDKIM has a large number of them.

I meant how the Authentication-Results header field would be changed to 
transport the result of this extension.

>> stopper for me.

Because SMTP is defined as a multi-recipient transport. If this 
extension would require a mandatory split of every message, then this 
has to be discussed at IETF-SMTP because the semantics of SMTP are 
changed. It is a big difference if the implementation of a mta decides 
to split all messages on arrival or if some ISPs decide to send only 
singe-recipient emails, or if a protocol extension requires mandatory 
splitting.

If a sender splits all emails because of some local advantage the sender 
forces the receiver to waist a lot of ressources for nothing. Instead of 
one message going through anti-spam several messages must be processed. 
For example, we are runnig amavisd+spamassassin in pre-queue mode to be 
able to reject spam on arrival (legal reasons). Splitting means we have 
to provide more ressources for parallel connections and/or to limit the 
number of connections per ip address or network which results in delayed 
messages.

> 
>> But I don't think this requirement is needed. I would allow a list
>> of recipients and have a paragraph which states:
> 
>> ===
>> signing of the message as is would result in the leakage of hidden
>> BCC recipients. The check has to be done in the following way:
>> 
>> * split the message and sign and send a single-recipient-copy of
>> the message with this recipient
> 
> We discussed the idea of tying it directly to To and Cc.  The downside
> of doing so is that participating DKIM implementations would have to
> know the syntax and semantics of RFC5322 header fields; right now it
> needs only very basic syntax information about them, just enough to
> run canonicalization.  It adds a whole lot of code complexity we'd
> rather avoid.  On top of that, if someone were to later register some
> other sender or recipient header field that should be included in this
> list, we'd have to update everything on the DKIM side by updating this
> list.
> 

I don't buy this argument. I would assume that every program which 
manipulates an email will use a library for this. Normally such a 
library will have a function call to extract the addresses from a header 
field. Using libopendkim you would use

**  DKIM_MAIL_PARSE_MULTI -- extract the local-part and hostname from a 
mail
**                           header field that might contain multiple
**                           values, e.g. "To:", "Cc:"

(BTW, the files dkim_mail_parse_multi.html as well as 
dkim_sig_setdnssec.html are missing in the distribution of OpenDKIM.)

How high is the probability that a new sender or recipient header field 
will be registered? And even if that's the case, that's not a big 
problem. The program would treat the addresses as BCCs until the 
administrator changes the config to use the additional field or an 
update of the program would incorporate this field.

> Simplicity is very desirable here, as is reaching across the layer
> boundary as little as possible.
> 
>> ===
>> 
>> If the submission MTA already enforces the handling of bcc
>> recipients as described in
>> https://tools.ietf.org/search/rfc5322#section-3.6.3 [1] the signing
>> can always be done.
> 
> This sort of thing might work if you also specify the way both ends
> will process this symmetrically.  Any ambiguity will result in
> interoperability problems.
> 

Sure, the algorithm has to be used on both sides otherwise it would make 
no sense.

>> Depending on an underlying policy from the administrator the "refuse
>> to sign with this extension" could mean
>> 
>> - to reject the message with an error like "Configuration error:
>> DKIM signing this message would leak BCC recipients"
> 
> These are purely implementation policy choices.  At best a
> specification like this one would lay them out as options in a
> non-normative way.

My specification part ended at '===' These examples should only show 
that more than one implementation is possible for the requirement 
"refuse to sign with this extension".

> 
>> This check and the resulting split action is RFC 5322 compliant.
>> However it would need to use the second variant of the bcc handling
>> with the single-bcc-recipient-email.
>> 
>> sense. It protects against passive attacks (just looking at the
>> header) but not against active attacks.
>> 
>> How about this?
> 
> It's worth considering further if we were to become convinced that
> this is a problem that needs to be solved in the form of changes to
> DKIM.  Right now I think we should wait for operators to explain why
> going down any of these paths is the best option.  My main worry is
> that it seems to invite a lot of complexity in code and either
> solution would introduce a lot of complexity into the problem space,
> possibly more than they really would solve.
> 

Sure, it must be evaluated, if this extension will give us enough value 
which would justify the additional costs of the implementation.

> -MSK
> 
> 
> 
> Links:
> ------
> [1] https://tools.ietf.org/search/rfc5322#section-3.6.3

Michael

---

From: Michael Storz <[email-masked]>
Date: Tue, 22 Nov 2016 17:10:23 +0100

Am 2016-11-19 15:22, schrieb John R. Levine:
> I'm with Murray -- why is this a problem?  Single recipient has been
> the de-facto standard for years, and unless you are extremely
> bandwidth constrained, it's faster.

No, it's not faster, see my answer to Murray. It's wasting a lot of 
ressources.

> See previous discussion.  We rejected multi-recipient signatures
> because of the bcc recipipient leakage.

John, did you read my email? The whole text is about how the leakage of 
the BCCs can be prevented and the feature of a multi-recipient email be 
preserved. If you see an error in the algorithm, please explain.

Regards,
Michael

---

From: "John R. Levine" <[email-masked]>
Date: 22 Nov 2016 11:14:34 -0500

> No, it's not faster, see my answer to Murray. It's wasting a lot of 

People who've measured say the elapsed time is faster, and the extra bytes 
on the wire don't matter.  This is an old argument, and not one you're 
going to win.

> John, did you read my email? The whole text is about how the leakage of the 
> BCCs can be prevented and the feature of a multi-recipient email be 

See previous messages, particularly the ones from Ned Freed.  Any sort of 
multi-recipient signing is subject to guessing attacks.

This isn't saying that signing the recipient is a good idea, but signing 
them individually is no worse than signing them together and avoids the 
leakage.

Regards,

---

From: Michael Storz <[email-masked]>
Date: Tue, 22 Nov 2016 17:38:03 +0100

Am 2016-11-22 03:15, schrieb Brandon Long:
> Also realize that this isn't "Gmail shouldn't sign spam", it's
> everyone who normally has a good reputation needs to not sign spam,
> this is a way to steal reputation from any service allowing you to
> choose your own message, and can be used against any mail receiver.
> 
> benefit, but one can combine the spf and dkim signals to try to combat
> this issue without introducing a new standard.  Forwarding will take
> the worst hit in false positives, but things like arc may help with
> that issue separately.
> 
> Brandon

The lesson I learned from discussing this draft is:

If you want to DKIM sign your messages you should either

- publish a SPF record (SPF gets mandatory) or
- include the discussed extension (in this case it looks like SPF is not 
needed anymore, SPF is optional)

and if a message leaves your ADMD you have to either

- DKIM sign it, if it originates from your ADMD or
- ARC sign it, if it is relayed through your ADMD (recipient has 
changed)

It is not enough to use ARC only in the case the message content has 
changed. It looks like only then a replay attack can be detected or 
mitigated.

Regards,
Michael

---

From: Michael Storz <[email-masked]>
Date: Wed, 23 Nov 2016 17:36:12 +0100

Am 2016-11-22 17:14, schrieb John R. Levine:
> People who've measured say the elapsed time is faster, and the extra
> bytes on the wire don't matter.  This is an old argument, and not one
> you're going to win.

Could it be, that we are talking about different things? I have no idea 
what these people measured. I can only talk for my site. Splitting all 
my internal traffic into single-recipient emails would mean an increase 
of 55%. If our mail servers would receive only single-recipient emails 
from the internet the traffic would increase by 13%. The processing of 
an email generates directly real cost in form of electricity and cooling 
etc. which has to be payed with real money. Processing all these 
additional traffic will give me no advantage but cost me real money. We 
try to avoid wasting ressources, Green IT is an important thing at our 
site, see http://www.lrz.de/wir/green-it_en/

> 
>> John, did you read my email? The whole text is about how the leakage 
>> of the BCCs can be prevented and the feature of a multi-recipient 
>> email be preserved. If you see an error in the algorithm, please 
>> explain.
> 
> See previous messages, particularly the ones from Ned Freed.  Any sort
> of multi-recipient signing is subject to guessing attacks.

Since this approach uses Neds alternative 0) b) for the BCC recipients 
no information about BCCs is leaked. This is the part where 
single-recipient emails are needed. But all other recipients can be put 
together into one email because their addresses are already recorded in 
the various header fields.

> 
> This isn't saying that signing the recipient is a good idea, but
> signing them individually is no worse than signing them together and
> avoids the leakage.
> 
> Regards,

Michael

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 23 Nov 2016 13:48:58 -0800

On Tue, Nov 22, 2016 at 7:45 AM, Michael Storz <[email-masked]> wrote:

> Because SMTP is defined as a multi-recipient transport. If this extension
> would require a mandatory split of every message, then this has to be
> discussed at IETF-SMTP because the semantics of SMTP are changed. It is a
> big difference if the implementation of a mta decides to split all messages
> on arrival or if some ISPs decide to send only singe-recipient emails, or
> if a protocol extension requires mandatory splitting.
>

As I understand it, the vast majority of mail you receive is very likely
single-recipient, and the vast majority of what you send is probably the
same.  Operationally this wouldn't change much.  On my personal machine,
the distribution looks like this so far today:

  23 nrcpts=0,
 319 nrcpts=1,
  17 nrcpts=2,

So forcing 100% of those messages to be single-recipient would add 17 more
messages, or just under 5% of today's flow so far.  I don't have immediate
access to data from a larger source.

SMTP is not "defined" as a multi-recipient transport.  It supports that as
an option but doesn't require it.  At best this proposal establishes a
required profile of its use, but doesn't change any protocol fundamentals.
MTAs would not have to be reimplemented, though the things that pass
messages to the MSA might.

> one message going through anti-spam several messages must be processed. For
> example, we are runnig amavisd+spamassassin in pre-queue mode to be able to
> reject spam on arrival (legal reasons). Splitting means we have to provide
> more ressources for parallel connections and/or to limit the number of
> connections per ip address or network which results in delayed messages.

That's true, but it doesn't change the SMTP model directly.  And given the
fact that statistically the vast majority of your mail is already
single-recipient, the cost you're concerned about here will likely be
minimal.  Or do you have contrary data?

> manipulates an email will use a library for this.
>

I don't think that's a valid assumption.  OpenDKIM happens to have the one
you cited, but in a pure sense no DKIM implementation actually needs it.
In fact OpenDKIM doesn't even really need it anymore now that it no longer
supports ADSP.  I should actually drop it.

> will be registered? And even if that's the case, that's not a big problem.
> The program would treat the addresses as BCCs until the administrator
> changes the config to use the additional field or an update of the program
> would incorporate this field.
>

Betting on who will do what in the future hasn't served us well in the
past.  Either way, I'm talking about the standards here.  RFC6376 did a
more hand-wavy job of listing, for example, which header fields to sign
than RFC4871 did, because we can't predict what sorts of header fields
might be registered later.  Instead, we talked about the general theory of
what should be signed versus which specific fields are in and which are out.

-MSK