Subject: Re: [dmarc-ietf] [Ietf-dkim] DKIM-Signature: r=y and MLM

From: Kurt Andersen <[email-masked]>
Date: Wed, 24 Oct 2018 14:18:48 -0700

On Mon, Oct 15, 2018 at 7:30 AM Hector Santos <hsantos=
[email-masked]> wrote:

<elided earlier part of the message>

> The rewrite should be the last thing to consider, and if it does
> rewrite, it should replace the original author domain strong policy
> with its own strong policy.
>
> For example, the ietf.org mailing list has begun to rewrite and it
> replaces the 5322.From with a dmarc.ietf.org domain, adds a new
> X-Original-From header and resigns the message using an ietf.org
> signer domain:
>
>    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org;
> s=ietf1;
>       t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=;
>       h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:
>       List-Archive:List-Post:List-Help:List-Subscribe:From;
>       b=.....
>     X-Original-From: Hector Santos <[email-masked]>
>     From: Hector Santos <hsantos=[email-masked]>
>
> What it should do is:
>
>    1) It should use a 1st party signature using d=dmarc.ietf.org to
>       match the new author domain dmarc.ietf.org.
>
>    2) It should has hash bind the X-Original-From header to the
>       signature.  Since DKIM recommends not to bind "X-" headers,
>       a non "X-" header should be used, i.e. "Original-From:".  This
>       means adding the header to the 'h=" field to avoid potential
>       mail resend exploits using different unprotected Original-from:
>       fields.
>
>    3) and finally, the dmarc.ietf.org domain should have its own
>       DMARC p=reject policy to effectively replace the one it
>       circumvented with the submission.
>

I don't understand why it is necessarily a bad thing to fall back to the
org domain (ietf.org) as this example shows.

I also don't understand how your suggestion would work to handle a mixture
of restrictive policies (some quarantine, some reject) with a single _
dmarc.dmarc.ietf.org record unless there is some trick DNS responder magic
going on (and that won't work well for cached responses anyway).

--Kurt

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Oct 2018 19:19:51 -0400

On 10/24/2018 5:18 PM, Kurt Andersen wrote:

> On Mon, Oct 15, 2018 at 7:30 AM Hector Santos
>
>     What it should do is:
>
>         1) It should use a 1st party signature using d=dmarc.ietf.org
>            to  match the new author domain dmarc.ietf.org
>
> I don't understand why it is necessarily a bad thing to fall back to
> the org domain (ietf.org <http://ietf.org>) as this example shows.

Because DKIM policy security was lost with the rewrite transaction.

Since the list agent took responsibility by performing a rewrite on a 
protected domain, it is reasonable to assume it would can restore the 
protection using its own secured list agent domain.  Without it, it 
leaves a security hole with the unprotected "X-Original-From" which it 
does not hash bind to the new signature.

> I also don't understand how your suggestion would work to handle a
> mixture of restrictive policies (some quarantine, some reject) with a
> single _dmarc.dmarc.ietf.org <http://dmarc.dmarc.ietf.org> record
> unless there is some trick DNS responder magic going on (and that
> won't work well for cached responses anyway).

If I follow your comment, the specific rewrite list agent domain can 
have its own strong p=reject or quarantine.  I don't see that as a 
problem.  It would not matter what the original author domain 
restrictive policy was. It doesn't have to match.

The original domain was protected with a strong  policy. The MLM 
rather than reject the submission, ignored the policy and rewrote the 
5322.From. It does this only for p=reject policies. I have not check 
if it does it for p=quarantine.   The rewrite should be done with a 
strong policy of its own to restore the original submission and author 
domain protection. The should also be a new first party signature 
(aligned).  At a minimum, the distributed message should bind the the 
altered header so that replays can be avoided.

-- 
HLS