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

Hector Santos <hsantos@isdg.net> Mon, 15 October 2018 14:30 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf-dkim@ietfa.amsl.com
Delivered-To: ietf-dkim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A782130E08 for <ietf-dkim@ietfa.amsl.com>; Mon, 15 Oct 2018 07:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=DHs7agIl; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=gHwj8zG/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMyaQoIuzxl2 for <ietf-dkim@ietfa.amsl.com>; Mon, 15 Oct 2018 07:30:47 -0700 (PDT)
Received: from ftp.catinthebox.net (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5506F130E7E for <ietf-dkim@ietf.org>; Mon, 15 Oct 2018 07:30:44 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6727; t=1539613838; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7cVOFgPyqWO+vHyk5h9Xc495rTc=; b=DHs7agIlyL6B4o5iFOhGsjco9RdbkYUrvfhBpyh2MKoMTAyhPRiRFq+0j3W+OV hoq4bGAJ3Cv66z61s6VQcREbkJmvFESxI6UQAUxaKpEFL4vHSDUgjoI59BPV8Wh5 n7KVGmH0hGHYuKimPoWs4hiQPzsZ6KfP+G8e5NjOFYf7g=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf-dkim@ietf.org; Mon, 15 Oct 2018 10:30:38 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3712445628.50760.4784; Mon, 15 Oct 2018 10:30:37 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6727; t=1539613077; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xYQTMpi D3ShJA0WuxTN+Wn010Tztg2xlKxwlFQ9Icuc=; b=gHwj8zG/L7+EHl0F/UP97Oh /RVj4T3uz5hyQS3Sb74+6b+njOuMZeF12GmUCw/Dcrw53rm5syQEF7w4LbTVKzJk tr0zZvqDTRWMMzgA0VzgEKD1np5jEG6oWC9EwZ7klHnr4Wotpg7XkePnhXtTCkK0 ESIQlbY5jasFMr/QpPCo=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf-dkim@ietf.org; Mon, 15 Oct 2018 10:17:57 -0400
Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3453806312.9.167724; Mon, 15 Oct 2018 10:17:56 -0400
Message-ID: <5BC4A48C.3080302@isdg.net>
Date: Mon, 15 Oct 2018 10:30:36 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: ietf-dkim@ietf.org, Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
References: <20180811033840.Horde.i6llD-AtvgzyNIjbhTs-nkS@webmail.aegee.org> <98aff90a-2198-854f-f1e6-85fd704cb7d1@tana.it> <20180817214834.Horde.DNYi60aPTo_sOKr7o3ilPra@webmail.aegee.org> <2c60b8bf-fec7-3a72-4bcc-3f2416e6f8b1@tana.it> <20180820193206.Horde.U24zQJh_TH-uC-4hxrcs2fw@webmail.aegee.org> <6e31890d3b63091a1d731fd70c2bfc217dc4f45b.camel@aegee.org>
In-Reply-To: <6e31890d3b63091a1d731fd70c2bfc217dc4f45b.camel@aegee.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/H6-e436Yh-tYC5ASEJkSmNjlSL8>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DKIM List <ietf-dkim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-dkim/>
List-Post: <mailto:ietf-dkim@ietf.org>
List-Help: <mailto:ietf-dkim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2018 14:30:50 -0000

On 10/10/2018 5:11 AM, Дилян Палаузов wrote:
> Hello,
>
> no feedbach means either everyboby agrees, nobody understands, or
> nobody cares.

Generally, a bit of everything.

I'm providing some comments because I am currently updating my DKIM 
ADSP/ATPS/DMARC implementation and need to take into account the MLM 
rewrite issue.

> I suggested introducing
> * fo=da in DMARC’s TXT [https://tools.ietf.org/html/rfc7489#section-6.3
> ] for sending reports on failed DKIM-Signatures, only when they align,
> and
> * introducing r=a in DKIM-Signature [
> https://tools.ietf.org/html/rfc6651#section-3.2] that only sends
> reports, when From: aligns.
>
> This way, once an email is intenionally modifed, the modifying software
> is aware that DMARC will trigger and rewrite From: so no distracting
> reports will be sent.

I don't think we need a new DKIM-BASE DKIM-signature tag for what you 
want.  This all starts with DKIM Policy (ADSP/DMARC) restrictive 
policies and receivers finally honoring them.  This could be better 
done as a DMARC tag extension where it provides the MLM more DMARC 
mail handling information.

For example, new DMARC tag extensions "rewrite=" and "fo="

   rewrite=no     default, rewriting SHOULD be avoided.
   rewrite=allow  allow rewriting by domain with a p=none or no policy
   rewrite=strict allow rewriting by domain with a p=reject|quarantine 
policy

   fo=da          send reports when rewriting is done

Keep in mind that not every system will send reports.  It is 
considered a high overhead with a high redundancy.  Our implementation 
does not generate reports.  Reporting adds a high barrier and 
technical implementation requirement.  Reporting should be optional 
for implementation.

Also keep in mind that the idea of "Rewriting" is not a "standard" 
concept.  It is actually a long time mail engineering taboo to be 
destroying the originating author field for any mail platform, 
including RFC5322. Its a very sensitive design idea. Our MLM package 
does not rewrite.

However, I am considering it now as a means to resolve the problem of 
errant DMARC/ADSP domains submitting public mailings using restrictive 
policies.   I personally believe the DMARC/ADSP receiver can implement 
ATPS "Authorized Third-Party Signers" (RFC6541) but that didn't gain 
traction, so rewrite appears to be the only recourse.    With more 
receivers now honoring the policies, it can cause a major havoc in a 
list subscription group.

Since there are more MLM systems performing DMARC-based rewrites, I 
believe a better way to deal with this is for the MLM to reject the 
restrictive domain submission with an email response:

    "Sorry, your submission was prohibited due to a protected domain
     restrictive DMARC|ADSP policy."

In fact, the MLM should stop all new subscriptions from domains using 
a restrictive policy.

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 <hsantos@isdg.net>
    From: Hector Santos <hsantos=40isdg.net@dmarc.ietf.org>

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.

With these measures, the original author domain will still be 
protected with a DMARC policy when the MLM rewrites.

That's my idea of a better approach to it as oppose to a blind, 
unprotected rewrite.

>> I am looking for a way to get reports only when somebody
>> unintentionally modifies an email.  The reason for this is
>> to have a system without unexplainable  failures that makes it
>> easy to fix broken DKIM signing/validating software.

Remember, not all systems will send a report.   I personally think a 
MLM should be playing an more active role to protect against DMARC -- 
who can subscribe, who can submit mail.  If the domain is restrictive, 
it is possible to maybe only allow READ-ONLY mode and/or add a user 
subscriber option that says:

     [_] Rewrite the From address is allowed

Although, it could just use the DMARC record to see if there is a 
"rewrite=no|allow|strict" option.  The MLM is now doing the DMARC 
lookup, so its possible now to add this logic.

    if rewrite=no then
       send submission/subscription prohibited message

    if rewrite=strict then
       if the mlm has no dmarc policy, then
          send submission/subscription prohibited message
       else
          do rewrite with new matching signer and author

    if rewrite=allow then
        do rewrite with new signer and author

    if rewrite= then  // no tag
       follow local mlm policy setup

>> How about introducing fo=da for sending reports on failed
>> DKIM-Signatures, only when they align?  This is much like having r=a
>> in DKIM-Signature that only sends reports, when From: aligns.  This
>> way, once an email is intenionally modifed, the modifying software is
>> aware that DMARC will trigger and rewrite From: so no distracting
>> reports will be sent.

I'm currently updating my DKIM implementation with DMARC 
ADSP/ATPS/DMARC, which basically means adding the local policy 
switches to finally honor the p=reject/quarantine policies.

This means that our MLM needs to do much of the above which is basically:

    1) During new subscriptions, check for restrictive domain.

    2) During list submissions, check for restrictive domain.

        (_) Don't allow, send notification
        (_) Allow rewrite with address ________________________
            [_] Optional check for DMARC 'rewrite=" extension

The main design consideration is to make sure the list submission is 
either prohibited or  corrected before the distribution and reaches 
DMARC receivers.

-- 
HLS