Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Scott Kitterman <[e-mail]>]

On Thursday, September 14, 2023 5:27:08 PM EDT Wei Chuang wrote:
> On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman <[e-mail]>
> 
> wrote:
> > On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> > > We had an opportunity to further review the DMARCbis changes more
> > > broadly
> > > within Gmail.  While we don't see any blockers in the language in
> > 
> > DMARCbis
> > 
> > > version 28
> > > <https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28> and
> > > can live with what is there, we wanted to briefly raise some concerns
> > > around some of the changes.  Two points.
> > > 
> > > Regarding the languages in section 8.6 "It is therefore critical that
> > > domains that host users who might post messages to mailing lists SHOULD
> > 
> > NOT
> > 
> > > publish p=reject.  Domains that choose to publish p=reject SHOULD
> > 
> > implement
> > 
> > > policies that their users not post to Internet mailing lists", we wanted
> > 
> > to
> > 
> > > point out that this is impossible to implement.  Many enterprises
> > > already
> > > have "p=reject" policies.  Presumably those domains were subject to some
> > > sort of spoofing which is why they went to such a strict policy.  It
> > 
> > would
> > 
> > > be unreasonable to tell them to stop posting to mailing lists as many
> > > likely already use mailing list services and will want to continue to
> > > use
> > > them.  The one thing that makes this tractable is the SHOULD language as
> > 
> > we
> > 
> > > may choose not to not follow this aspect of the specification.  Our
> > > suggestion is that there is not a lot of value in including this
> > > language
> > > in the bis document if the likely outcome is that it will be ignored,
> > > and
> > > rather more effort should be placed with a technical solution for
> > > interop
> > > with mailing lists.
> > 
> > It might be helpful if you could describe this technical solution from
> > your
> > perspective.
> > 
> > If there were a reasonable technical solution available, I think this
> > would be
> > a much easier change to support (in my opinion, and a believe a
> > substantial
> > number of others, rewriting From is not a reasonable technical solution).
> > 
> > Scott K
> 
> Apologies for the delay in getting back to this.
> 
> So yes I believe there are two possible technical approaches broadly
> speaking 1) Support rewriting From and being able to reverse it along with
> message modifications to recover the original DKIM message hash to validate
> the original DKIM signature.  2) Create a new message authentication method
> that is tolerant of message modifications and message forwarding, and
> supported by DMARC.  From header rewriting would not be necessary in this
> scenario.  Beyond the complexity of supporting either method, another
> tricky thing in both cases is supporting an ecosystem with diverse adoption
> of said technique.  More concrete proposals for 1) and 2) are 1)
> draft-chuang-mailing-list-modifications
> <https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/>
> and 2) draft-chuang-replay-resistant-arc.  And there are other I-Ds out
> there particularly for the first approach.
> 
> -Wei

Thanks.  That's helpful.

I interpret that as confirming my view that there is not currently a reasonable 
technical solution available.  While these may be promising for the future, 
it's not like any of those solutions are things that are currently available 
to email list administrators.

I don't think any of those things are going to mature quickly, so I would find 
it concerning to delay publication of DMARCbis until they are ready.  If we 
aren't going to put DMARCbis on ice for a few years (please, let's not), then 
I think we're left with something like the language that's there now or some 
variation of NOT RECOMMENDED unless [unobtainium] which amounts to the same 
thing, but is in my view less clear.

I think in a couple of years we could do some kind of an update that relaxes 
the current language based on one of these techniques if they become 
deployable, but I don't think we can do it now.

Scott K