Re: [dmarc-ietf] ARC questions

Michael Thomas <mike@mtcc.com> Mon, 23 November 2020 19:46 UTC

Return-Path: <mike@fresheez.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 0FE953A0D47 for <dmarc@ietfa.amsl.com>; Mon, 23 Nov 2020 11:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.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 xhHr61zdxqRD for <dmarc@ietfa.amsl.com>; Mon, 23 Nov 2020 11:45:59 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 DE3BE3A0D44 for <dmarc@ietf.org>; Mon, 23 Nov 2020 11:45:59 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id 18so9355052pli.13 for <dmarc@ietf.org>; Mon, 23 Nov 2020 11:45:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/3r8PY7qQXrpEItm3TDgiO5QrNVuXF9infgfidIrMuY=; b=tA27iROcnwTJELH7lYlKRTM3FsiF7xASQ+tM4+i0WE9HSGBQFq2vmYoGA5S+7vhz4U 1L7CBkmYWXLkaiOpyfp2rIeZ5uyVRqQv8xGvmm5WgT0BftJbhBIb2qr7/ex8D48Sv47h EcJ78iSkgltc+hBn4XCEU9PMtfhII6DQso6WsOSMb+XQladAUjo6G8MMgYKJrnweghA1 kUflKAyDZCFljhsX+puXPZJ1ABhB9CBrT41zdkIQfvJy72rV/l831yoJppWoXTFqnUFs vJr8G5i76kZZHFXhLIa+kWaYBD5VdJecfInrLhXHQ4IoaDWuk+S0Fe7GsI5+tNclQVND FLcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/3r8PY7qQXrpEItm3TDgiO5QrNVuXF9infgfidIrMuY=; b=UeS+McPGBv/BbXHNyrGO7toem/f8EHvHav2AAslov6eLhRi94No4L+H6muS489IOc+ VQip2oBDYmEnW32f60Y35RdAl0aZDk/PjrCTdG2FPywrXYR/O0tT3yj4S/BFazDOL9zH FZZXw6wLwFzwaIWkzGSLkVv37UjykxX6G5O6ffb1y/nJ+GYF8VbZqLO77MrjmO6ss4Wt 8IoxDuLmeRsL49XAGDFPnP5c5cRDx2oDLHUw8W4vwq/VA+CYKR5LQy0YdpqLerfh5ut2 SaNM8i6L5Y81CL9ly+63Q0DLakGJ+bdrPhtDdssxP/+zumdyC4s/mw1rSkSUzk9bFDIl z1jQ==
X-Gm-Message-State: AOAM533+zwX5DEkVwHyh6cNVXkfsv3+DIjGA2mdSFMNcNVRurqMeTBtb c2B9MixBaFsLrKNirZxWGJnldE+ugIo+KA==
X-Google-Smtp-Source: ABdhPJyTg1zpHwBeSa2KUZVJV3MrXw9nh/JbF+ho5Tx9W9dKQuTSfKceq5CHNo8JSZ2qxdkIKhYCDQ==
X-Received: by 2002:a17:902:b689:b029:d8:f07f:7336 with SMTP id c9-20020a170902b689b02900d8f07f7336mr882219pls.53.1606160758864; Mon, 23 Nov 2020 11:45:58 -0800 (PST)
Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id q5sm10791219pff.36.2020.11.23.11.45.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 11:45:58 -0800 (PST)
To: John R Levine <johnl@taugh.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
References: <dcc265f9-a143-5093-eba0-94ee059c7cc7@mtcc.com> <20201122021417.B5E6E27B3E59@ary.qy> <CABuGu1pX=5ZC4RLsv19qrosRN9nCrPdeSk5Xg4O7ViEZit6dnA@mail.gmail.com> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <feac41f-6144-2e21-c3fa-2b7770bfeefc@taugh.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com>
Date: Mon, 23 Nov 2020 11:45:56 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <feac41f-6144-2e21-c3fa-2b7770bfeefc@taugh.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/KNJD1uXiqIaivINsUEeWRLsJI4k>
Subject: Re: [dmarc-ietf] 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: Mon, 23 Nov 2020 19:46:01 -0000

On 11/23/20 11:28 AM, John R Levine wrote:
>> From what I can tell, the main thing that ARC is doing is binding an 
>> auth-res to a dkim signature-like thing. But as I recall -- it's been 
>> a long time -- there were ordering requirements ala received headers 
>> for where new dkim-signatures and auth-res go in the header. Assuming 
>> my memory is correct, that means you can reconstruct "what this 
>> looked like before i messed with it" already by signing the incoming 
>> auth-res as part of the new DKIM signature.
>>
>> Is there something more going on here?
>
> Not really.  There are ordering rules but mail systems do not follow 
> them reliably, DKIM signatures in practice are not ordered.  Also, A-R 
> can be deleted in some situations, so ARC makes copies of them to be 
> more robust in transit.
>
If auth-res is sometimes deleted, why wouldn't we expect the arc 
auth-res to not be deleted too?

I imagine that the vast majority of intermediaries that break signatures 
number exactly one extra domain, so it's not very hard to reconstruct 
the chain of custody from origin to destination. Assuming the 
intermediary resigns with the incoming auth-res, the destination can 
choose to believe that auth-res or not, right? Since this is an 
experiment, do we have an idea of what the rest of the problem is after 
the typical mailing list-like signature breakers are excluded?

Mike