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

Alessandro Vesely <vesely@tana.it> Sat, 05 December 2020 13:21 UTC

Return-Path: <vesely@tana.it>
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 2DFEF3A0B08 for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 05:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 B6cGR2JN3p87 for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 05:20:59 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 154913A0B05 for <dmarc@ietf.org>; Sat, 5 Dec 2020 05:20:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607174455; bh=FJJ9m2RB8fy7AqgnXKA8alc0llUYo36nKoxWeFhAeHY=; l=5668; h=To:Cc:References:From:Date:In-Reply-To; b=CJDhFSX1RrK6J8g3Z7UXmS35DnaeM9KtQvz936aqu+SxN6l4Te5hzMPi+t89QuH9r fgwgHdpfr4C5KFUlc8rrEp/42FEFhhNKXJ2eilNX8MsQFwfhgAU673enhLVxKNkpWU FTLdQLx1Inqk0HEH2ZIdOajcYb6Bm3/uI6MCQbOhHnrFjHQX6EI/PIEw9fsrA
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Original-Cc: IETF DMARC WG <dmarc@ietf.org>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005FCB8937.00000ACB; Sat, 05 Dec 2020 14:20:55 +0100
To: Brandon Long <blong@google.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
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> <CABa8R6us3cKfYa=tmkiZho087BfLH=Ga92JYxMiHW0Zb4btm8g@mail.gmail.com> <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it> <CABa8R6spYyZDhzEnQ=txdoLOO1Ek1MAryW6ioAsur1_mEvdXkA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <dff10989-b2cd-8cbd-f465-46796028d320@tana.it>
Date: Sat, 5 Dec 2020 14:20:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CABa8R6spYyZDhzEnQ=txdoLOO1Ek1MAryW6ioAsur1_mEvdXkA@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/J4oObL3tdTlwCYJrhxQHfmpmbbI>
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: Sat, 05 Dec 2020 13:21:01 -0000

On Fri 04/Dec/2020 23:45:47 +0100 Brandon Long wrote:
> On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely <vesely@tana.it> wrote:
>> On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote:
>>> 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. >>
>> That's ARC.  If a message lacks DKIM and was SPF-authenticated, there's
>> no way it can continue to be authenticated through a relay. >>
>> OTOH, mailing lists and relays are two different beasts.  For one thing,
>> it is very unusual for a mailing list to send to another mailing list.
>> Thus, we can safely specify a non-stackable authentication method. >
> mailing list to mailing list mail is very common in GSuite, but maybe we're 
> a special case.  Part of that was that aliases were moved to the mailing 
> list infra (which is definitely more of an "our problem" than everyone), but 
> we also see common usage where companies make groups matching their 
> hierarchy (the all company group goes to all department groups which go to 
> all local groups etc).  We also see some where announce groups mix contrib 
> groups, etc.  Especially since we also use the same groups as ACL groups for 
> GSuite and Google Cloud, so hierarchical groups are very common.

I'm not familiar with that feature.  How does a list get subscribed to another 
list?

In general, a list accepts messages from subscribed users, so if dmarc-ietf 
distributed this message to another list which I'm not a subscriber of, it 
would not pass.  (From: rewriting changes that behavior.  For example, one 
could subscribe to a list which routinely rewrites From: on behalf of this 
list, dmarc-ietf.  If the former list traffic is very high, that subscribing 
could be a sort of DoS attack to us.)


> (there was a recent common where someone said who needs an org chart when 
> we have email, showing the list of footers for all of the org level mailing 
> lists the message went to to get to them)

The mlm-transform draft (referenced above) limits footers to 10 lines of text, 
each shorter than 80 characters.  If the hierarchy is not deeper than 10,  the 
chart can fit within a single footer.  Note that every added line breaks all 
previous signatures.  However, only the author domain's signature is worth 
being recovered, as far as MLM transformations are concerned.  ARC can still 
certify the whole chain.

The 10 lines limit is arbitrary.  It is meant to avoid that recipients mistake 
the footer for the main part of the message.


> (one construction of hierarchical announce lists that was not well 
> considered did result in every person on the combined list getting 9000 
> copies of messages to the list, so flattening lists is sometimes much 
> preferred) >
> Which isn't to say we couldn't work around it or do the work to flatten the 
> lists, though it increases the complexity of the product (can you 
> unsubscribe from the top level list but not a sub list?)

I guess some coordination among sublists is required anyway.

To recognize that a message arrives from a sublist, and hence mangle the 
existing footer instead of adding a new one, is certainly an added complexity. 
  Maybe, the number of lists in such condition is low enough to let MLM 
transformation reversion still worth being deployed?


Best
Ale
--