Subject: [dmarc-ietf] draft-kucherawy-dmarc-rcpts

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 Nov 2016 15:50:05 +0900

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.

-MSK

---

From: Steven M Jones <[email-masked]>
Date: Sun, 13 Nov 2016 11:40:39 -0800

On 11/12/2016 22:50, Murray S. Kucherawy wrote:
> 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.
>

Thanks for codifying this proposal Murray.

So per Section 5, this form of DKIM signature will fail to verify at a
receiver who doesn't implement the new feature, period. And in fact any
forwarding - whether it alters the RFC5322 message or not - would
produce a DKIM verification failure at the next/final recipient.

The language in Section 5 paragraph 3 seems to cover envelope splitting.
Should this be expanded to address origin ADMD infrastructure such as
split signer/MTA, analogous to the note about split MTA/verifier at the
receiving ADMD in paragraph 4?

Are there any usage guidelines or recommendations about how and when to
use the new signing feature that I missed? For example is there another
draft, or a thread in a different forum/list, that speaks to this? If it
doesn't exist, do we need to create one? (Ulp - did I just volunteer?)

I'd be curious to get feedback from folks who aren't enamored of ARC,
but understand the motivating abuse...

Thanks,
--Steve.

---

From: Vladimir Dubrovin <[email-masked]>
Date: Mon, 14 Nov 2016 00:01:04 +0300

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).
2.3 Canonization must be better defined. It's usual for MTA to e.g.
lowercase the domain of recipient.

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)

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.

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

13.11.2016 9:50, Murray S. Kucherawy пишет:
> -
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: [email-masked]
Date: Sun, 13 Nov 2016 15:40:59 -0800 (PST)

> 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.

> 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.

> 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

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.

> 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?

> 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.

> 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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 14:43:28 +0900

> produce a DKIM verification failure at the next/final recipient.

Correct.

> receiving ADMD in paragraph 4?

Do you have a use case in mind that's not addressed by the text that's
there?  It seems to me the text that's there specifically covers any kind
of split regardless of where in the handling chain the split occurs.

> doesn't exist, do we need to create one? (Ulp - did I just volunteer?)

I think this work is small enough that any such guidance can just be
included here, probably in Section 5.  Essentially, you use this if you
want to defend against this particular type of attack and are also prepared
to take on the additional cost (second signature, potential
misunderstanding by verifiers and receivers).

> but understand the motivating abuse...

I don't think there's any plan with this work to supplant or augment ARC,
in case that's what you're implying.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 14:57:22 +0900

On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin <[email-masked]>
wrote:

> implementations. It makes it useless. In addition, in it's current form it
> can not be implemented in most MTAs (see below)
> 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.
> 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.

> lowercase the domain of recipient.

That's a good point.

> 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.

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 15:04:57 +0900

> 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?

> 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.

> sites single copy may be a requirement already.

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

> 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.

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

-MSK

---

From: Vladimir Dubrovin <[email-masked]>
Date: Mon, 14 Nov 2016 12:25:43 +0300

14.11.2016 8:57, Murray S. Kucherawy пишет:
> aren't you basically doing the same thing I'm proposing, other than
> where it gets recorded in the message?
>

 Consider e.g.

random_salt = crypt_random()
recipient_sig = as_enc(recipient_pubkey, as_enc(sender_privkey,
random_salt + hash(recipient_address)))

DKIM-Transport-Sig: recipient_sig(recipient_address1),
recipient_sig(recipient_address2), ...

only receiving MTA  can check the presence of it's own address in the
header (salt must be different for every address in the header), so it
solves all Bcc leakage issues except every recipient is aware of the
number of recipients,  and there is no need for recipient to know ALL
recipients, that is it solves all transport issues. In addition, because
it uses header, it's compatible with current DKIM implementations.

Validation:

for every recipient_address in envelope (or in local delivery, it
doesn't matter)
    calculate hash(recipient_address)
for every recipient_sig in DKIM-Transport-Sig
    decrypt random_salt+hash(recipient_address) from recipient_sig with
as_enc(recipient_privkey,                      
as_enc(sender_pubkey(recipient_sig))
    remove random_salt to get hash(recipient_address)
    for every recipient_address in envelope
        compare calculated and decrypted hash(recipient_address), if
matches mark recipient_address as valid

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Hector Santos <[email-masked]>
Date: Mon, 14 Nov 2016 13:19:35 -0500

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
> 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