Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

Brandon Long <blong@google.com> Wed, 02 December 2020 02:15 UTC

Return-Path: <blong@google.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879673A0F22 for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 18:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 po_nxZ3qu-ib for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 18:15:01 -0800 (PST)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4497D3A0EA9 for <dmarc@ietf.org>; Tue, 1 Dec 2020 18:15:01 -0800 (PST)
Received: by mail-vs1-xe35.google.com with SMTP id x26so130614vsq.1 for <dmarc@ietf.org>; Tue, 01 Dec 2020 18:15:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KQomLLiscGwc9NoB5b7VJsq6u7jD/j1GbhPWXXITkFM=; b=VpJfJMlhsxyk22GdGC1k0DcetHRXFPAN4IUs/QVs/S48ZXA0G49f1fMC1kZFC+Pnrt L5Xfd/LnkUK4cN9IOhZiXMmPh4bAddKn/0NPHpDbg0nkiL6BMpkGnOJ4Pe+5DgpTaNHj 8UksaEb609C3ri7ykHfDZGu+p6fVdq/Xub6/65+nu/lKoZM8wOXOlKkzcuuxlbnR4Vns CZBY9d3Ci1/llanBl1j71LfcEj5akPigF7m1nScsjlqVaHRtinhH/BNKnIbYXKXblG1d v9ecZTYM3urmqvWNmCEHeWoloQ1HGg4DPQux6wl+yrCaCbQ6qu2NTDugUX27bLKaxm8k Qxow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KQomLLiscGwc9NoB5b7VJsq6u7jD/j1GbhPWXXITkFM=; b=ODUpezjR2sBVcri2MGPSqAweyIySphzWiqTG9wJimjFicMp8IhMzTv0oMWL2ZA8oBO ub5LAP8ucI5kFXrxRjZB8pWV4ZxMh1xuavgNPcBDkQJs/xxltI9Zpb08RpomY+lCCGf5 m18KGwLXvp490gPm8lWel6CoZd80eMPB/1rz6FIP7o9CD/cjIXUDPl8ex9EU90uz4b+h 3tlJ+U6Gv9dN62rutUlBVYHwh/DOFk94UKyu58ldLsWKSdSU67rqUom5Br6c2FfT4Hkw vIhe8Z0zkj5teot5cJmcRtR3sTpihgyMqHjboecDpLzgZRE/ivqnJaQLivFrZcTgdeU0 mVmA==
X-Gm-Message-State: AOAM530T5zjs2JX8KBuILuDQyyTyuWe/AJzxs0py3GaLObEZ/cfd4WOp NVPSvu8kHRfXW8lQJHQzzUPcrt0MTbFQb4NMrrPm
X-Google-Smtp-Source: ABdhPJy8sSz3dt0uYBiYyOz/hkfqrOcpY1d5jcsnS0SYonOX4qM+2dJ2c6HvXP9fESGdkEcFVsK00inJBjA+399ytcA=
X-Received: by 2002:a67:df8b:: with SMTP id x11mr207892vsk.37.1606875299775; Tue, 01 Dec 2020 18:14:59 -0800 (PST)
MIME-Version: 1.0
References: <e9166148b9564102a652b4764b4f61ff@com> <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <b0f72407-81ce-9990-4a5b-7b0e5b76e3d7@mtcc.com> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <CABa8R6sV0x8wWmggp98JfXz8jh0GfAmZ+tNkvqnMPnVK534uPQ@mail.gmail.com> <e54e9ff4-59ae-a2ac-7ae9-a8036528a24f@tana.it>
In-Reply-To: <e54e9ff4-59ae-a2ac-7ae9-a8036528a24f@tana.it>
From: Brandon Long <blong@google.com>
Date: Tue, 1 Dec 2020 18:14:46 -0800
Message-ID: <CABa8R6us3cKfYa=tmkiZho087BfLH=Ga92JYxMiHW0Zb4btm8g@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000717d5e05b571cf81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DD6t-dY7zhiPEw2BQGkTilcn2Lk>
Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 02:15:07 -0000

On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:
> > On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <vesely@tana.it>
> wrote:
> >
> >> On 25/11/2020 20:16, Michael Thomas wrote:
> >>> On 11/25/20 11:11 AM, Alessandro Vesely wrote:
> >>>> On 25/11/2020 19:24, Jesse Thompson wrote:
> >>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote:
> >>>>>> Without resorting to ARC, it is still possible to validate author
> >>>>>> domain's signatures directly if the MLM just adds a subject tag
> >>>>>> and a footer>>>>>
> >>>>> I agree that ARC isn't really needed to do this (trust the last hop
> >>>>> from the MLM and determine the original authenticity from the MLM's
> >>>>> perspective)>>>>
> >>>> I didn't mean to trust the MLM.  I meant remove the subject tag and
> >>>> the footer, then the original DKIM signature verifies.  See:
> >>>> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
> >>>
> >>> When I was at Cisco, with l= and some subject line heuristics I could
> get
> >>> probably like 90+% verification rate across the entire company, a
> company that
> >>> uses external mailing lists a lot. Definitely not 100% though.
> >>
> >>
> >> DKIM itself is not 100%.  You always have lines beginning with "From "
> or
> >> occasional autoconversions.
> >>
> >> l= doesn't cover multipart/alternative nor Content-Transfer-Encoding:
> >> base64. In addition, the DKIM spec discourages its usage and suggests
> >> that "Assessors might wish to ignore signatures that use the tag.">>
> >
> > Right, some of the other dkim-light or diff concepts we discussed would
> be
> > better than using l=
> >
> > We again got hung up on the 100% solution, though... something that
> handled
> > subject-prefix and footer in a transport agnostic way might have worked.
>
> I'm not clear about the meaning of "100%".  If an author domain puts no
> DKIM signatures, there is no way to verify them.  Hence, some compliance of
> the author domain has to be required.
>
> The same holds for conditional signatures.
>
> The same holds for MLM transformations.
>

Yes, by 100% I meant of messages that were already authenticated and
therefore should continue to be authenticated through
the relay.

Some of the conditional signatures of the "include a diff you can remove to
validate the original" attempt seemed to
fail on the theory that there were too many things that couldn't be
handled.  Ie, if your relay removes attachments,
including them back in a diff kind of breaks the whole point of that... but
how common is that (even less now with
Yahoo Groups gone, but possibly still some av/malware relays still do this).

I think that one issue we've had is that DMARC is very mechanical and
straight-forward, so anything that's fuzzy
in response seems more complicated.

Anyways, what I'm saying is that I agree, we may have discarded things that
might have been much easier/simpler
for the 90% case due to wanting something that worked for everything.


> > The fact that DKIM isn't transport agnostic is an achilles heel to even
> > that, though, since we'd have to come up with a new canonicalization and
> get
> > it to widespread adoption before the simple diff could work.
>
> As DKIM works in the vast majority of cases (yes, not 100%, but nearly),
> the idea to discombobulate it for the sake of a meagre set of old-fashioned
> individuals who still dislike mass social media is a showstopper.  Yet,
> since DMARC standardization itself avails of mailing lists, we may want to
> get some coherence.
>

There are decided benefits to DKIM being MIME/body unaware, I was merely
pointing
out that there are things we could do if it was not and part of why some of
these alternatives were not pursued.


> > Or require mailing lists to be a lot more strict in how they do their
> email
> > rewriting, but I imagine that's harder work than even ARC.
>
> They are quite strict already.  For example, I received the message I'm
> replying to in both my top and dmarc folders.  Both copies of the message
> have the correct From:.  The MLM copy was authenticated like so:
>
> Authentication-Results: wmail.tana.it;
>   spf=pass smtp.mailfrom=ietf.org;
>   dkim=pass reason="Original-From: transformed" (whitelisted) header.d=
> google.com;
>   dkim=pass (whitelisted) header.d=ietf.org
>     header.b=zA0RRbSR;
>   dkim=fail (signature verification failed, whitelisted) header.d=ietf.org
>     header.b=F65GxYqF
>
> From: restoring is documented here:
> https://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans


That's cool, I thought when I looked at the mailman code (admittedly a long
time
ago) that it didn't really concern itself with that level of maintaining
the format
of the message.  Unfortunately, the Google Groups code isn't that strict
either,
though we could have fixed that for a lot of cases (there's always the
challenge
of inserting a footer that requires changing the charset or cte).

Brandon