Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Brandon Long]

On Tue, Nov 22, 2016 at 8:05 AM, John Levine  wrote:
>
>
> >And, if you think about it, spam is in the eyes of the recipient.  If you
> >take this message I'm composing right now and send a couple billions
> copies
> >to the top 10 mailbox providers, how many spam markings will it get?  With
> >some of the spammers we deal with, all they're looking for is clicks on
> the
> >links in the email, there is nothing particularly commercial about the
> >content itself.
>
> Now I'm really confused about what problem we're trying to solve here.
> You are of course right that there are messages that become spam if
> they're remailed a zillion times, but there are also messages that
> don't.  If I send a message to, say, nanog, it goes to a lot of
> people, the DKIM signatures usually survive, and it's not spam.
>
> If the bulk remail is spam, that will presumably affect the reputation
> of the places from which it is remailed.  That's not enough?
>

In a reputation based system, you take reputation on various features of
the message, and whether or not a message is spam depends on all of those
features, and then feeds back into each of those features.

So, the IPs for the botnet the message is spammed from will certainly take
a hit, or may already be bad.  The reputation of the dkim auth domain is
likely also to suffer, though.

In an IPv6 world, domain auth may play a higher role than IP for
reputation, given the high number of IP addresses.

Of course, the obvious mitigation there is to be more careful of dinging
dkim auth when spf auth doesn't pass or match.

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Brandon Long]

Well, besides the obvious damage of phishing/spam mails that may make it
through filters because of this, yes, this can also be used to damage the
reputation of senders.

Gmail can probably weather the reputation issue, since we're a large high
volume service, and antispam folks would have to mitigate in order to let
through the regular high volume of "good" mail.  Users tend to hate false
positives more than false negatives.  Same with most high volume / well
known senders.

It's the medium senders who are can be caught in a bind, effectively
blacklisted.  It's kind of like IP reputation or blacklisting if your
server gets owned and is used to send spam, cleaning up after that is a not
fun for the admin.  Previously, most systems wouldn't have blacklisted a
server for literally sending a single spam message (maybe if the recipient
happened to be a particularly strong spam trap, but that would be pretty
amazing).  Now, a single spam message can be multiplied into blacklisting
by dozens of mailbox providers.

And, if you think about it, spam is in the eyes of the recipient.  If you
take this message I'm composing right now and send a couple billions copies
to the top 10 mailbox providers, how many spam markings will it get?  With
some of the spammers we deal with, all they're looking for is clicks on the
links in the email, there is nothing particularly commercial about the
content itself.

To believe that you can keep email "the same as it's been" and prohibit
sending even a single weaponizable message is to ignore reality.

That said, at this point most of the major mailbox providers have had to
deal with this and have some level of mitigation in place.   The rate at
which we can deploy a new protocol to fix an attack like this is always
going to be challenging, but it may be that this attack will continue and
move down market in time, so a protocol could be available as other folks
are abused or targeted.  None of that speaks to whether this proposal is
the right solution or if there is a good one.

Brandon

On Nov 21, 2016 4:27 PM, "Murray S. Kucherawy"  wrote:

What's the actual damage here?  Does, say, gmail.com's reputation suffer
when it signs spam that then gets replayed?

On Mon, Nov 21, 2016 at 4:04 PM, Brandon Long  wrote:

> In examples we've seen, the mail is delivered to a host and immediately
> (seconds) picked up by the spammers botnet and millions of copies sent.
>
> Short of charging an exorbitant amount of money per message sent, I don't
> see how any service can prevent sending a single spam message with 100%
> accuracy.
>
> Brandon
>
> On Nov 15, 2016 12:52 PM, "Murray S. Kucherawy" 
> wrote:
>
>> On Wed, Nov 16, 2016 at 5:11 AM, Michael Thomas  wrote:
>>
>>> So, when the filters catch up, it will then mark it as spam again
>>> regardless of the DKIM signature.
>>>
>>> So what exactly is the problem here?
>>>
>>
>> I suppose when the filters catch up, the spammer can no longer get
>> $HIGH_REPUTATION_MAIL_SERVER to sign that message until the next hole is
>> discovered.  But everything submitted and replayed prior to that has
>> already gone out and been delivered on the basis of that reputation.
>>
>> That's the problem here.
>>
>> -MSK
>>
>> ___
>> NOTE WELL: This list operates according to
>> http://mipassoc.org/dkim/ietf-list-rules.html
>>
>>
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 5:11 AM, Michael Thomas  wrote:

> So, when the filters catch up, it will then mark it as spam again
> regardless of the DKIM signature.
>
> So what exactly is the problem here?
>

I suppose when the filters catch up, the spammer can no longer get
$HIGH_REPUTATION_MAIL_SERVER to sign that message until the next hole is
discovered.  But everything submitted and replayed prior to that has
already gone out and been delivered on the basis of that reputation.

That's the problem here.

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Michael Thomas]

On 11/15/16 11:57 AM, Murray S. Kucherawy wrote:
On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten 
> wrote:


My understanding is an attack where the email is sent to an outside
address owned by the sender, who then gets a copy of the email, signed
by the provider who didn't think the email was bad.

Signing an email that you know is bad does indeed sound like a bad
idea.


There's always some time window between a spammer discovering a new 
technique that gets past filters and those filters learning about the 
new attack via whatever ML is in use.  That might be when this attack 
is most effective.  You can't label as spam that which you don't 
identify as spam.


So, when the filters catch up, it will then mark it as spam again 
regardless of the DKIM signature.


So what exactly is the problem here?

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten  wrote:

> My understanding is an attack where the email is sent to an outside
> address owned by the sender, who then gets a copy of the email, signed
> by the provider who didn't think the email was bad.
>
> Signing an email that you know is bad does indeed sound like a bad
> idea.


There's always some time window between a spammer discovering a new
technique that gets past filters and those filters learning about the new
attack via whatever ML is in use.  That might be when this attack is most
effective.  You can't label as spam that which you don't identify as spam.

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Michael Thomas]

On 11/15/2016 11:17 AM, Martijn Grooten wrote:

On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote:

Not at all.  As I understand the scenario, the provider knows it's
bad, doesn't send the mail on to the outside world, but still gives a
signed copy back to the originator (which is then available for
replay).

My understanding is an attack where the email is sent to an outside
address owned by the sender, who then gets a copy of the email, signed
by the provider who didn't think the email was bad.

Signing an email that you know is bad does indeed sound like a bad
idea.



That's not how i read it, but even if it was it would still require the 
mail be signed by a provider which presumably should pass judgment on it
to decide to sign or not. If they signed something bad, they own the 
ding on their reputation, or whatever.


It's not like you can change the bits in the mail once they're signed 
and still keep a valid signature, so I'm not seeing what the problem is 
here.


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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Martijn Grooten]

On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote:
> Not at all.  As I understand the scenario, the provider knows it's
> bad, doesn't send the mail on to the outside world, but still gives a
> signed copy back to the originator (which is then available for
> replay).

My understanding is an attack where the email is sent to an outside
address owned by the sender, who then gets a copy of the email, signed
by the provider who didn't think the email was bad.

Signing an email that you know is bad does indeed sound like a bad
idea.

Martijn.


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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Scott Kitterman]

On November 15, 2016 10:53:19 AM CST, Martijn Grooten 
 wrote:
>On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote:
>> OK.  Ultimately, "don't sign spam" has got to be the solution or
>reputation is 
>> going to suffer, so I think they are going to have to eventually bite
>the 
>> bullet and fix it.
>
>I think you underestimate how difficult it is to detect spam in cases
>like this. Good spam, from a spammer's point of view, looks like
>legitimate email, except that it's sent in bulk, or links to some bad
>site (malware/phishing), or has a malicious attachment. The attachment
>aside, none of this has to be present when the first instance of the
>email is sent (and signed). And even detecting new malware isn't as
>trivial as it may sound.

Not at all.  As I understand the scenario, the provider knows it's bad, doesn't 
send the mail on to the outside world, but still gives a signed copy back to 
the originator (which is then available for replay).

Given that scenario, they've already done the hard part.

All the protocol solutions being discussed have huge negative implications for 
email.  I've yet to see a proposal I think should be implemented (my suggestion 
about a now DMARC policy option still seems the least bad to me, but I don't 
particularly like it).

Scott K

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Martijn Grooten]

On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote:
> OK.  Ultimately, "don't sign spam" has got to be the solution or reputation 
> is 
> going to suffer, so I think they are going to have to eventually bite the 
> bullet and fix it.

I think you underestimate how difficult it is to detect spam in cases
like this. Good spam, from a spammer's point of view, looks like
legitimate email, except that it's sent in bulk, or links to some bad
site (malware/phishing), or has a malicious attachment. The attachment
aside, none of this has to be present when the first instance of the
email is sent (and signed). And even detecting new malware isn't as
trivial as it may sound.

Martijn.



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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Hector Santos]

On 11/13/2016 1:50 AM, Murray S. Kucherawy wrote:> I've posted a draft 
that attempts to address an attack that's begun to

appear with DKIM.  Interestingly, we called it out as a possible
attack in RFC6376 and even RFC4871, but now it's apparently happening
and being annoying enough that people (I believe from the MAAWG
community) are asking if there's a protocol solution that's possible.

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/



Thanks for the write up.  I'm just now reading this (a quick review) 
and I have several points to make about this effort:


From what I read so far, this is 1::MANY distribution issue and less 
of a 1::1 direct, private email path issue but the 1::1 path is being 
exploited to prepare a 1::many distribution at some systems?


Not excluding another possible tech solutions/proposals to close this 
"security loophole,"  the code changes required are significant, both 
at the signer and verify. With integrated systems, passing the 
distribution list to the signer is required.  There is much change to 
be considered.


If it promotes code changes, then we should consider other DKIM 
related situations as well to be included in what is essentially an 
DKIM Update.  For example, John's double signature proposal can be 
considere, and in addition, we could also review the "i=" AUID 
identity to see if it can help.  Our package can the i= for list 
distributions.


But this here bothers me:

   9.  Implementation Status

   The next release of OpenDKIM will implement this proposal.  OpenDKIM
   is in widespread use, including at very large installations, so use
   and utility of this extension can be easily observed.

Since this is a security loophole, I'm concern that this proposal 
needs a very thorough review, including reviewing other proposals and 
solutions. You could be jumping the gun to implement something that 
will be harder to pull back and once again, the IETF needs to remember 
that not everyone uses OpenDKIM.


Thanks for your consideration


--
HLS


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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Scott Kitterman]

On Monday, November 14, 2016 05:34:19 PM Murray S. Kucherawy wrote:
> On Mon, Nov 14, 2016 at 4:37 PM, Scott Kitterman 
> 
> wrote:
> > >Doesn't that presuppose point-to-point handling?  The proposal here
> > >doesn't.
> > 
> > Your proposal breaks all non-point-to-point handling, if I understand it
> > correctly, so whether you make DKIM signatures non-forwardable or do it in
> > DMARC policy, it's the same end result.
> 
> How does it break all non-point-to-point handling?  It does break if the
> envelope has to change, but that's not what I think of when you say
> "point-to-point"; it makes me think of mail from A to C that happens to
> transit B, which should survive just fine.

Within an ADMD, internal relaying should survive just fine, since, as you say, 
RCP TO doesn't change, but I don't think that's an interesting case.  Email 
authentication check tend to be very fragile if not done at the edge of the 
ADMD for lots of reasons.

What I was thinking of was non-point-to-point handling while between two 
ADMDs.  Typically mailing lists or transparent forwarding.  In both of those 
cases, RCPT TO changes.  One set of advice given to mailing list operators 
about DMARC has been to change their list setup so that they don't break DKIM 
signatures (and some have done that).  This proposal would make that 
impossible.

Between two ADMDs, you would not be able to change RCPT TO, so it would have 
to go direct.  At that point, if you engage DMARC alignment requirements on 
the SPF check, you achieve the same result.

Also, if you make this a DMARC policy choice, then the added restrictions 
associated with restricting changes to RCPT TO only affect senders that have 
opted into the policy choice.

> > I think your pushing a substantial change to DKIM and to the extent this
> > is a reasonable problem to solve, DKIM isn't the right layer in the email
> > authentication stack to do it.
> 
> Ah, yes, that's a plausible argument.
> 
> > I think the solution to "I have a problem that results when I sign spam"
> > is "don't do that", not the entire community turns on its head to work
> > around someone's local configuration problems.
> 
> Yes, I agree that's the preferable solution.  It sounds as if there are
> some operators (well, at least one, I think) that are having a problem for
> which "don't do that" is an expensive solution, and a question has been
> posed about the possible existence of an easy, incremental protocol
> solution for it.  It's fine if the answer is "no", but I'd like to have the
> discussion without prematurely slamming any doors.

OK.  Ultimately, "don't sign spam" has got to be the solution or reputation is 
going to suffer, so I think they are going to have to eventually bite the 
bullet and fix it.  I don't think an opt-in extension to DMARC like I suggest 
above is unreasonable and I think it would be able to be deployed more 
quickly.  So far though, I don't see fixing it in DKIM as a good way to go.

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Scott Kitterman]

On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy" 
 wrote:
>On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman
>
>wrote:
>
>> Wouldn't a DMARC option to allow senders to specify only messages
>that
>> pass verification and alignment for BOTH SPF and DMARC accomplish the
>same
>> result with less complexity and without the layering violation
>inherent in
>> this proposal?
>>
>
>Doesn't that presuppose point-to-point handling?  The proposal here
>doesn't.

Your proposal breaks all non-point-to-point handling, if I understand it 
correctly, so whether you make DKIM signatures non-forwardable or do it in 
DMARC policy, it's the same end result.
>
>> DMARC seems to be the policy engine of choice in the community (for
>better
>> or for worse).  I think addressing this at the policy level makes
>more
>> sense than changing the semantics of DKIM signatures after almost a
>decade
>> of deployment.
>>
>
>As the problem was presented to me, I haven't heard that DMARC is
>specifically involved here.  It might be (maybe even "probably" is
>apt),
>but I haven't heard that, so I limited this idea to just the DKIM
>signing
>and verifying components of the system.

I think your pushing a substantial change to DKIM and to the extent this is a 
reasonable problem to solve, DKIM isn't the right layer in the email 
authentication stack to do it.
>
>> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately
>> convinced I'd want to enable this feature.  I don't know if other
>distro
>> maintainers are on this list or not, but that's one opinion.  It's
>not
>> guaranteed to be widely deployed.
>>
>
>Why is this a distribution issue?

Because so far this looks like a source of interoperability problems and bug 
report headaches I could do without.

I think the solution to "I have a problem that results when I sign spam" is 
"don't do that", not the entire community turns on its head to work around 
someone's local configuration problems.

Scott K

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed  wrote:

> > Actually same message to same destination may be
> > sent to different MTAs (e.g. different MXs with same weight).
> > 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> > lowercase the domain of recipient.
>
> Our default is to leave the case of addresses alone by default, but sites
> often
> do configure things to "right case" their business name. That said, Early
> validation would avoid such issues for us. I think.
>

Long ago some MTAs use to mess with the case of the domain names in the
envelope.  Assuming some of them are still out there, wouldn't we want to
fold everything to lowercase (or uppercase; pick one) before doing the sort?

> All problems except 2.1 may be fixed by adding additional header, like
> e.g.
> > DKIM-Transport-recipients
> > which contains salted hashes (with some random salt) of all recipient
> > addresses, and require this header to be added to DKIM signature and
> > existence for every recipient's address' hash to be checked in this
> > header. It is compatible with any current DKIM implementation.
>
> If you're talking about hashing all recipients together, then I don't see
> this
> solving all the problems except 2.1.
>
> And if you're talking about hashing them separately, then why would you
> insist that they all be present?
>

I think he's trying to avoid being clobbered by an envelope that gets split
downstream.  If you as a verifier have the full original recipient set,
then all you care about is that your recipient set is a subset of the
original set.


> But limiting the number of recipients to 1 when this extension is used
> would be
> a much simpler approach. Of course there's some overhead involved in doing
> this, but given the idiotically limited spam report mechanisms in place at
> some
> sites single copy may be a requirement already.
>

It's also the most common use case in threat space, as I understand it.


> Finally, my biggest concern here is that this, like most proposals that
> involve complex linkages between the header and envelope, is complex
> and loaded with pitfalls. (Just look at these two messages...) And at least
> some of this spills over to both implementations and operational policy.
>

Indeed; I don't think that's avoidable if we want to try to tackle this
problem versus punting it back up to layers 8 and 9.  But maybe that's the
best thing one can do.

Can we really expect people to get this right?
>

I wonder that every time I write a draft anymore.  :-)

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin 
wrote:

> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form it
> can not be implemented in most MTAs (see below)
> 2. This standard mixes transport standards (SMTP) and message standard.
> There are multiple issues as a result of this:
> 2.1 Same message may have multiple recipients on different MTAs while each
> MTA only sees it's own recipients. So, destination MTA can not verify
> signature, because it doesn't know all recipients. This can be fixed if
> message to every destination is  signed independently, but it breaks
> existing mail flows, because in most cases message is signed before placing
> to MTA queue.
> 2.2 Recieving MTA may e.g. limit the number of recipients and single
> message may be sent to different final recipients on the same MTA in
> multiple session as few different messages, each message with partial list
> of recipients. Actually same message to same destination may be sent to
> different MTAs (e.g. different MXs with same weight).
>

Yes the current text in the document already calls all of those issues out.


> 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> lowercase the domain of recipient.
>

That's a good point.


> All problems except 2.1 may be fixed by adding additional header, like e.g.
> DKIM-Transport-recipients
> which contains salted hashes (with some random salt) of all recipient
> addresses, and require this header to be added to DKIM signature and
> existence for every recipient's address' hash to be checked in this header.
> It is compatible with any current DKIM implementation.
>
2.1 can also be solved in this case, but it disclosures BCCs of the message
> (even if this header is removed before delivery to mailbox)
>

Also an interesting idea.


> All problems may be solved by using asymmetric encryption instead of
> hashing, e.g. require domains with support for this standard to publish
> some public key (or to use special DKIM selector) via DNS record and
> encrypt recipient's addresses in the additional header with public key and
> only sign recipients for systems with this key published.
>

If you do asymmetric encryption, with or without a distinct selector,
aren't you basically doing the same thing I'm proposing, other than where
it gets recorded in the message?

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman 
wrote:

> Wouldn't a DMARC option to allow senders to specify only messages that
> pass verification and alignment for BOTH SPF and DMARC accomplish the same
> result with less complexity and without the layering violation inherent in
> this proposal?
>

Doesn't that presuppose point-to-point handling?  The proposal here doesn't.


> DMARC seems to be the policy engine of choice in the community (for better
> or for worse).  I think addressing this at the policy level makes more
> sense than changing the semantics of DKIM signatures after almost a decade
> of deployment.
>

As the problem was presented to me, I haven't heard that DMARC is
specifically involved here.  It might be (maybe even "probably" is apt),
but I haven't heard that, so I limited this idea to just the DKIM signing
and verifying components of the system.


> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately
> convinced I'd want to enable this feature.  I don't know if other distro
> maintainers are on this list or not, but that's one opinion.  It's not
> guaranteed to be widely deployed.
>

Why is this a distribution issue?

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[ned+dkim]

> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form
> it can not be implemented in most MTAs (see below)

It wouldn't work at all in our MTA without modifications because our general
filter interface currently receives recipient addresses after some processing
has been performed. We could add an option to change that fairly easily, but as
you note, that doesn't address all the issues.

> 2. This standard mixes transport standards (SMTP) and message standard.
> There are multiple issues as a result of this:

> 2.1 Same message may have multiple recipients on different MTAs while
> each MTA only sees it's own recipients. So, destination MTA can not
> verify signature, because it doesn't know all recipients. This can be
> fixed if message to every destination is  signed independently, but it
> breaks existing mail flows, because in most cases message is signed
> before placing to MTA queue.

We have sufficient flexibility in this regard to sign late (and as noted
above, verify early), and we can split by destination before signing
each variant separately.

What would be much more difficult is detecting this usage and turning off
splitting where feasible to avoid breaking the signature. That would be very
difficult.

The bottom line is that at best this will be very fragile, at worst it will
fail a significant percentage of the time.

> 2.2 Recieving MTA may e.g. limit the number of recipients and single
> message may be sent to different final recipients on the same MTA in
> multiple session as few different messages, each message with partial
> list of recipients.

Actually, this quickly turns into a hairball. The minute the receiving
system starts 4yz'ing some recipients the precomputed signature is going
to be rendered invalid and will have to be recomputed.

And how does the receiving MTA know when do this? It gets no indication
that it's dealing with this particular DKIM variant until after recipients
are processed. So it's only choice would be to do it unconditionally, or
to try and keep track of senders who use this feature.

Yuck.

> Actually same message to same destination may be
> sent to different MTAs (e.g. different MXs with same weight).
> 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> lowercase the domain of recipient.

Our default is to leave the case of addresses alone by default, but sites often
do configure things to "right case" their business name. That said, Early
validation would avoid such issues for us. I think.

> All problems except 2.1 may be fixed by adding additional header, like e.g.
> DKIM-Transport-recipients
> which contains salted hashes (with some random salt) of all recipient
> addresses, and require this header to be added to DKIM signature and
> existence for every recipient's address' hash to be checked in this
> header. It is compatible with any current DKIM implementation.

If you're talking about hashing all recipients together, then I don't see this
solving all the problems except 2.1.

And if you're talking about hashing them separately, then why would you
insist that they all be present?

> 2.1 can also be solved in this case, but it disclosures BCCs of the
> message (even if this header is removed before delivery to mailbox)

Prior to delivery the bcc's are disclosed by being present in the envelope. So
as long as the sender adopts the approach of splitting by destination before
signing, only including the recipients for a given copy in the signature, and
the receiver removes the field prior to final delivery, I think it might
work.

But limiting the number of recipients to 1 when this extension is used would be
a much simpler approach. Of course there's some overhead involved in doing
this, but given the idiotically limited spam report mechanisms in place at some
sites single copy may be a requirement already.

> All problems may be solved by using asymmetric encryption instead of
> hashing, e.g. require domains with support for this standard to publish
> some public key (or to use special DKIM selector) via DNS record and
> encrypt recipient's addresses in the additional header with public key
> and only sign recipients for systems with this key published.

Yes, and that's really cute. Considerable overhead though.

> P.S. I just did a quick look into standard, sorry if I missed or
> misunderstood something.

So did I, and so do I.

Finally, my biggest concern here is that this, like most proposals that
involve complex linkages between the header and envelope, is complex
and loaded with pitfalls. (Just look at these two messages...) And at least
some of this spills over to both implementations and operational policy.

Can we really expect people to get this right?

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

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Scott Kitterman]

On November 13, 2016 1:50:05 AM EST, "Murray S. Kucherawy" 
 wrote:
>I've posted a draft that attempts to address an attack that's begun to
>appear with DKIM.  Interestingly, we called it out as a possible attack
>in
>RFC6376 and even RFC4871, but now it's apparently happening and being
>annoying enough that people (I believe from the MAAWG community) are
>asking
>if there's a protocol solution that's possible.
>
>https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/
>
>Comments welcome.

Wouldn't a DMARC option to allow senders to specify only messages that pass 
verification and alignment for BOTH SPF and DMARC accomplish the same result 
with less complexity and without the layering violation inherent in this 
proposal?

DMARC seems to be the policy engine of choice in the community (for better or 
for worse).  I think addressing this at the policy level makes more sense than 
changing the semantics of DKIM signatures after almost a decade of deployment.

Scott K

P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately convinced 
I'd want to enable this feature.  I don't know if other distro maintainers are 
on this list or not, but that's one opinion.  It's not guaranteed to be widely 
deployed.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html