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

Dilyan Palauzov <Dilyan.Palauzov@aegee.org> Mon, 20 August 2018 19:32 UTC

Return-Path: <Dilyan.Palauzov@aegee.org>
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 E31BA12F1A5 for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 12:32:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 FUiF3RpC6_12 for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 12:32:09 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2816F128CF3 for <ietf-dkim@ietf.org>; Mon, 20 Aug 2018 12:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1534793527; i=dkim+sm-localhost@aegee.org; r=y; bh=P5nez5VY2S2B6WWDsSMir1c56hsqY4ydbwa9ZXC3npo=; h=Date:From:To:Subject:References:In-Reply-To; b=FUAzEWk4qNmN1YbFblWKJdNn9FRU84sIS8YNTQsgjMZ6JMWQ96k2KSgL8dXx3P10/ rZn2LAjYfMflyqAq8PdzSh/uSIfZx2+gfwKI+F52Qj+/pFsxZSgyRXt2GBdEjYkvER gFHr+q3nbftU7QIleqm3Viyu86UbLcR4b+JTF6Affos05Db1KKrDrCgMLb//oudifY FxlEUlErhsuCK24dfgrCicR4W5dAgDoHgTKei78qIvFqV6GH5dOz6t6RE0msviTDgV lJsRXaZAuucEqpAKRrk69aUDOnW814BFhieX67FlvYBEDxwOif5VlbTzJqCbV77hlw uobGjsoMYi3/9Rqu1ooDlQdg5+LjM2t2cwwnOSBZO4u49tCjoVm1BAqXvD+/OuKOKV 5zCX++1dTqnhwU04To+5Bv20YKabrSNqkcHh/jkNEW4lJ3eEfaCHnBX/UWgS19q6CP yIV9SbdMRntzPDVUgjtqlFWZx9IGXE625qIp/EnXEO8MAlDMWSI9eQ0i3RzlFqthry Hy99Zokah1TnHdF7fQXs6/OUwanyt/GUNTbyycYyjexv36X/96QkME6+5HVo3pytMm WRZaOjvGLjIf5YvRosJYxVe5/dCz3s1zQ4OZPVS/9U8zFwc0xKCHgQ7ehLk7dWA0E+ 16XxzWV1dF2+fVdnmo0AMRA8=
Authentication-Results: mail.aegee.org/w7KJW6PE009854; dkim=none
Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id w7KJW6PE009854 for <ietf-dkim@ietf.org>; Mon, 20 Aug 2018 19:32:06 GMT
Received: from c-76-102-151-26.hsd1.ca.comcast.net (c-76-102-151-26.hsd1.ca.comcast.net [76.102.151.26]) by webmail.aegee.org (Horde Framework) with HTTPS; Mon, 20 Aug 2018 19:32:06 +0000
Date: Mon, 20 Aug 2018 19:32:06 +0000
Message-ID: <20180820193206.Horde.U24zQJh_TH-uC-4hxrcs2fw@webmail.aegee.org>
From: Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
To: ietf-dkim@ietf.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>
In-Reply-To: <2c60b8bf-fec7-3a72-4bcc-3f2416e6f8b1@tana.it>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.1 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/n1hUEGTdQGGsmPE-cz2t0TCrZ7k>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.27
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, 20 Aug 2018 19:32:12 -0000

Hello,

for fo=d is written:

          Generate a DKIM failure report if the message had a signature
          that failed evaluation, regardless of its alignment.  DKIM-
          specific reporting is described in [AFRF-DKIM].

Once From: is rewritten by MLM, DKIM-Signature is preserved and does  
not align anymore, fo=d;ruf=mailto: will generate a report.

How is fo=d different than having r=y?  I want to get repors about  
failed DKIM validation only when the email was unintentionally  
modified, or sender and verifier are not implemented correct and use  
different logic to calculate the hashes.

Do you suggest to include in RFC 7489bis (DMARC) everything from RFC  
6651, except r=y and ADSP?

Removing r=y from DKIM-Signature is indeed untrackable operation, but  
why should it be?  DKIM-Signatures are partially self-signed, however  
I proposed to remove r=y only when DKIM-Signature is intentionally  
invalidated and in this case the signature is not damaged additionally  
by removing r=y.

I do not insist on removing r=y from DKIM-Signature.  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.  Repeating myself, when the aggregate reports show that 1%  
of the emails are signed wrongly, there is no way to debug the problem  
and fix.  Before this fixed DMARC cannot be introduced, neither for  
incoming nor for outgoing mails.

Some suggest to remove DKIM-Signature when the mail is modified  
intentionally (by MLM), mailman logic is to keep the invalidated  
DKIM-Signatures on their path to implement ARC

I don't like the idea of sending reports about unaligned  
DKIM-Signatures (rewritten From: by MLM), as this allow a mailing list  
subscriber posting to the list to get a list of all subscribers, but  
the list of subscribers might be private.

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.

Greetings
   Дилян

----- Message from Alessandro Vesely <vesely@tana.it>; ---------
    Date: Mon, 20 Aug 2018 11:31:09 +0200
    From: Alessandro Vesely <vesely@tana.it>;
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
      To: ietf-dkim@ietf.org


> Hi!
>
> On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote:
>>
>> I cannot provide very useful experience:
>
> Thank you for the overview.  Albeit low-volume, it confirms my feeling that
> rfc6651 is not widely adopted.
>
>> [...]
>>   - state explicitly that providers who want reports about mismatched
>>     DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=...
>
> ruf= suffices.  p=reject;pct=0; is to force MLMs to rewrite From:, so as to
> avoid useless reports.  However, what one deems useless could be interesting
> for another; for example, one might use aggregate reports triggered by MLM
> sending as a sort of delivery notification, thereby achieving a  
> partial list of
> subscribers' domains.  One-man-and-for-fun provider's subscription is easily
> betrayed that way.
>
>
>> Why shall software that knows r=y is old-fashion not remove it from
>> DKIM-Signature:, in order to ensure that r=y is not interepreted later by
>> software, that doesn't know r=y was moved to historic?
>
> Let me recall that the DKIM-Signature header field is implicitly signed; that
> is, if you alter it any way, it won't verify any more.  Removal of  
> r=y would be
> nearly impossible to undo, unless you know r=y was present and where  
> exactly it
> was placed.  Remove the whole field or rename it to, say, Old-DKIM-Signature.
>
> BTW, some signatures are weak enough to survive boilerplate changes.  In that
> case, the signer might be interested in verification failures even after MLM
> changes.  How would you treat that instance?
>
> Best
> Ale
> --
>
>
>
> _______________________________________________
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim


----- End message from Alessandro Vesely <vesely@tana.it>; -----