Re: [dmarc-ietf] ARC questions

Michael Thomas <mike@mtcc.com> Tue, 24 November 2020 23:57 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 6A20B3A08EB for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 15:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ilaQeM1Hf_bY for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 15:57:22 -0800 (PST)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 D47B63A08DA for <dmarc@ietf.org>; Tue, 24 Nov 2020 15:57:22 -0800 (PST)
Received: by mail-pf1-x42c.google.com with SMTP id x24so607193pfn.6 for <dmarc@ietf.org>; Tue, 24 Nov 2020 15:57:22 -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-language; bh=UogYqTpKNUNb+Jk+qB7u5PvZNb6a8gX8A9QCPzAr47M=; b=c8s0w6ZNEfn+2AVyy0uCDTWbWJdShHFydvELM21nIuSmEx/sQ1e2c3Gfe7cy/dKkv/ ZTzydIUZxICzyK+WHkUq7SjkceIjbcA8S+/3jzqfAhDZ7zxYQQ9fFBc/fukQ0oeR/rMu N659iVXYy6CupAUFnqxD/y282iRaj6Iq7eQtFDi9agP+X1RUQyuArDUn3Sru0GXzqEuC 5tYTdWk9k02Z3f2EcFeuU3800hm+zceuBcnKmhr+u8XwMF2BCFuM2ZjV/1PRAsQK16sw BUm1/ueMVmU//cpT6fIbp1lz2L/1jk59qYtVPosAyGjfjYvENi13YwRYzaIO26+YWt+V aN7A==
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-language; bh=UogYqTpKNUNb+Jk+qB7u5PvZNb6a8gX8A9QCPzAr47M=; b=fdXMRygx00g7TtM+3MX5AwQU+c089ytAxv1ELT3SSMp0Mml7DlTTDXAY0/0pAmll0k VImqX8MD7ez0Z2Y+Pnd1dsh7JdqZv2fmwLCDGFv3ndMjPVd2UYerMmL19zsT9UJchWTM K8JQd735c5yTCWjwHYe5au1eaIAKPPc/WUP+CLGnoWvzI3VjZCOfVM/dSCbieKKfAZt3 Y3718S4S6QUav+qJvL/pTX/G4Hq4xCgHoRnb7aAruN7kY0u0c8750vNW4tB96vb7uxtL vo1i/YIiG6LYINw3MhWecaTJ3eS3CQxX+TlekGqFwh8aTu0T8JZehz+r+lh+bOedEJwA UUKg==
X-Gm-Message-State: AOAM531dHo+l8EXXmznk0Jkw4TpqpAO7fLeQ2mJrRUq+OQqSF4vX3nR0 iUbfp73yQOUmp5PDrs+syzrxHivOihcWKA==
X-Google-Smtp-Source: ABdhPJx2iJBwjwM5ZOJAMSiZop0IlMhWl0/cPUHEWMK67Sc5+OSguazPHd0PTgsTM4NsNP0mtx9WUQ==
X-Received: by 2002:a17:90b:234b:: with SMTP id ms11mr786435pjb.110.1606262241891; Tue, 24 Nov 2020 15:57:21 -0800 (PST)
Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id z7sm138762pfr.140.2020.11.24.15.57.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 15:57:21 -0800 (PST)
To: Brandon Long <blong@google.com>
Cc: John Levine <johnl@taugh.com>, IETF DMARC WG <dmarc@ietf.org>
References: <20201124020453.AFDC027CE5C8@ary.qy> <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com> <CABa8R6s0bfs87Fu9eOq_R3WH1pngauVXrw3RSPe9iWWCtf3AmQ@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <c954eadd-5c85-c0d9-2168-8a42de506b72@mtcc.com>
Date: Tue, 24 Nov 2020 15:57:19 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CABa8R6s0bfs87Fu9eOq_R3WH1pngauVXrw3RSPe9iWWCtf3AmQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4E8397D5A8C93E9FE8464FF0"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kZ7Ap5AcrtUBMhISAOMCc7UDXio>
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: Tue, 24 Nov 2020 23:57:24 -0000

On 11/24/20 3:24 PM, Brandon Long wrote:
>
> On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas <mike@mtcc.com 
> <mailto:mike@mtcc.com>> wrote:
>
>
>
>     Sorry, changing the auth-res to old-auth-res and dkim signing the
>     message would be completely sufficient, and far easier to understand
>     with a lot less bloat. All of this hand wringing about dozens of
>     message
>     manglers in the path before it get to the destination and not be
>     able to
>     figure out which auth-res was which seems wildly out of proportion
>     for
>     what the normal case is: 1 message mangler in the path before it
>     arrives
>     at the receiver's domain. Just like this message right here.
>     That's why
>     I asked how common that was, which was dismissed, but not answered.
>
>
> Note that this was exactly what we started with, 
> X-Original-Authentication-Results
> and with Google's implementation signing that with 
> X-Google-DKIM-Signature.
>
> Our version didn't just sign with DKIM-Signature because of the 
> reasons already stated in this
> thread, that our understanding of how DKIM-Signature was being used 
> made it a poor choice.


Sorry, I didn't see that. Pointer?

>
> Our experience also showed that more than one hop is quite common in 
> enterprise deployments,
> and those are also the places where the most complexity arises.  
> Others shared our experience
> as well.

That's more than one modifying intermediary in *separate* administrative 
domains? Within your own administrative domain there shouldn't be an 
issue of trust since you can trust your own servers auth-res and that 
they are not maliciously trying to forge an auth-res for better 
treatment. and course it's best to stop a bad message as soon as 
possible in the mail pipeline if for no other reason than why waste the 
resources.


>
> You say that your message had 1 mangler in the path, but really you 
> don't know that.  It is
> likely that some people on this list are on enterprise accounts who 
> are behind mangling inbound
> gateways (rewriting urls to go through safety checking hops is common, 
> for example).  Or maybe
> they are on with University accounts using exchange but forward their 
> mail to a personal or department
> gmail account.


Well sure, I'm sure it can happen but is it common enough to worry 
about? And I'm still not convinced that figuring out who signed what and 
which auth-res it belonged to is in insurmountable problem. for one, 
there are received headers which better not be getting out of order to 
help correlate with the messages' path through intermediary verifiers too.

Mike