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

From: Дилян Палаузов <[email-masked]>
Date: Wed, 10 Oct 2018 09:11:45 +0000

Hello,

no feedbach means either everyboby agrees, nobody understands, or
nobody cares.

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.

Greetings
  Дилян

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.

On Mon, 2018-08-20 at 19:32 +0000, Dilyan Palauzov wrote:
> 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 <[email-masked]> ---------
>     Date: Mon, 20 Aug 2018 11:31:09 +0200
>     From: Alessandro Vesely <[email-masked]>
> Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
>       To: [email-masked]
> 
> 
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-dkim
> 
> ----- End message from Alessandro Vesely <[email-masked]> -----
> 
> 
> _______________________________________________
> Ietf-dkim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-dkim

---

From: Hector Santos <[email-masked]>
Date: Mon, 15 Oct 2018 10:30:36 -0400

> no feedbach means either everyboby agrees, nobody understands, or

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.

> is aware that DMARC will trigger and rewrite From: so no distracting

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

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

>> aware that DMARC will trigger and rewrite From: so no distracting

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

---

From: Дилян Палаузов <[email-masked]>
Date: Wed, 24 Oct 2018 20:32:09 +0000

Hello,

let me recall, that the reports on r=y are generated by software, that
is aware of DKIM, but not necessary of DMARC.  Therefore I think this
should be solved at DKIM-level.  At the same time these reports are
DMARC’s fault, as the latter forces the MLMs to rewrite RFC5322.From.

Verifying at the moment of subsription whether a domain is “good” or
“bad”, leads nowhere, as on the next day a “good” domain can be changed
to “bad”.

Moreover, providing an email address is an universal service. 
Providers do no offer emails in one domain for MLM that rewrite
RFC5322.From addresses and one domain for all (other) ocassions.  Such
an option will lead the users to use only the domain, that can send
anywhere.  Changing anyhow policy for current domains is also bad idea,
as this would mean users will have to subscribe to mailing lists again,
using a different domain (from the same provider).

Moreover, users writing to an email address cannot know for sure, if
the recipient address is a mailing list and therefore they can neuther
choose the correct domain for sending, nor there is any control when
subscribing them on the mailing list (as they do not get subscribed).

Providing universal MLMs that work with all email providers, is not
compatible with RFC6541 (DKIM Authorized Third-Party Signatures).  To
my understanding this means authorizing all possible domains do sign,
which is equivalent to not using DKIM.

I think on the fact, that MLMs add footers and [subject-tags] nothing
is going to change and in turn on further rewriting RFC5322.From also
nothing is going to change.

The fo=da, as suggested by me, was meant only for sending reports, not
when rewriting is done.  The point of the report is to informed
somebody, when the signing/verifying implementation fails.  Rewriting
is not an error, I do not understand what shall the reader of a report
sent on rewriting do with such a report.

The problematic reports on this thread, are not sent by the MLMs.  The
challenge is to send a report, when the signing/verifying software has
defficiencies, but not when RFC5322.From rewriting happened.  In the
latter case (rewriting happened) it cannot be said, whether the
verifying/signing software has bugs.

Greetings
  Дилян

---

From: Дилян Палаузов <[email-masked]>
Date: Wed, 24 Oct 2018 20:53:03 +0000

>       circumvented with the submission.

Please describe the handling, of the above message by the MLM, if the
original message contained in addition
  DKIM-Signature: v=1; d=isdg.net; r=y; …

... or something different than r=y, that permits finding faulty DKIM
implementations.

Apart from this, on the last email I sent “To: Hector Santos <
[email-masked]>, [email-masked]” , I got:

Date: Wed, 24 Oct 2018 20:32:15 GMT
From: Mail Delivery Subsystem <[email-masked]>
Message-Id: <[email-masked]>
Content-Type: multipart/report; report-type=delivery-status;
        boundary="w9OKWFSc027376.1540413135/mail.aegee.org"
Content-Transfer-Encoding: 8bit
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

--w9OKWFSc027376.1540413135/mail.aegee.org

The original message was received at Wed, 24 Oct 2018 20:32:10 GMT
from ipbcc2def0.dynamic.kabel-deutschland.de [188.194.222.240]

   ----- The following addresses had permanent fatal errors -----
<[email-masked]>
    (reason: 554 REJECTED BY SYSTEM POLICY FILTER)

   ----- Transcript of session follows -----
... while talking to mail.isdg.net.:
<<< 554 REJECTED BY SYSTEM POLICY FILTER
554 5.0.0 Service unavailable

--w9OKWFSc027376.1540413135/mail.aegee.org
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.aegee.org
Received-From-MTA: DNS; ipbcc2def0.dynamic.kabel-deutschland.de
Arrival-Date: Wed, 24 Oct 2018 20:32:10 GMT

Final-Recipient: RFC822; [email-masked]
Action: failed
Status: 5.5.0
Diagnostic-Code: SMTP; 554 REJECTED BY SYSTEM POLICY FILTER
Last-Attempt-Date: Wed, 24 Oct 2018 20:32:15 GMT

---

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

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Oct 2018 21:34:37 -0400

> ... or something different than r=y, that permits finding faulty DKIM

Our DKIM implementation does not support this "r=y" tag.  In general, 
per DKIM specification, all unknown DKIM-signature tags are ignored.

> Last-Attempt-Date: Wed, 24 Oct 2018 20:32:15 GMT

Off hand, it appears your IP address was filtered by a Geo IP Location 
database.  This is done immediately at the connection level so we have 
limited SMTP session logs to look at.

I'm contacting you off list.

-- 
HLS