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

[Дилян Палаузов <[e-mail]>]

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
  Дилян



On Mon, 2018-10-15 at 10:30 -0400, Hector Santos wrote:
> 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 <[e-mail]>
>     From: Hector Santos <hsantos=[e-mail]>
> 
> 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.
>