Re: [dmarc-ietf] Question regarding RFC 8617

"Kurt Andersen (b)" <kboth@drkurt.com> Thu, 07 November 2019 17:23 UTC

Return-Path: <kurta@drkurt.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 DD7F612093F for <dmarc@ietfa.amsl.com>; Thu, 7 Nov 2019 09:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 DGdKGfY2oIXw for <dmarc@ietfa.amsl.com>; Thu, 7 Nov 2019 09:23:53 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 64A191209C3 for <dmarc@ietf.org>; Thu, 7 Nov 2019 09:23:53 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id c11so3142101iom.10 for <dmarc@ietf.org>; Thu, 07 Nov 2019 09:23:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ShNK/t1sS3qCwQJfgKAsHxMbDjZ9eNSLPrNMZ50PGMc=; b=C6AeXZmblszcQZbP2aysant8AqAiIgyPLRpFe8aArGU6eTcQDp/NQ7QkIbYE/sTr+v N2/Vi964cqw+3SrRFGEr2yq/OCSSnWuhnrnNxtkWi9RuGzQq2qPDI7BJyhtiP21pAF6t RPD12BDBJZpy3NJKGlqTpMns6xBSQsvcIh6/g=
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=ShNK/t1sS3qCwQJfgKAsHxMbDjZ9eNSLPrNMZ50PGMc=; b=qhAsrXzFZiqslMWXCBM+42rvVmdfAgIlKCqQxRH4/HGOn3eUVKmDY3wXj/wgxdNcmO /qUNQg2gGkAmsIWLV6P+8hZX8rXnrWPv8Gx+fYuqVBZ75biPtlzIQoUXgIDMc0P+07a+ 2TCfPmO26dCq0o9jfKlolXbDA1awYIhnB3x5Uhj5aRCgB4aN+fgzNINImpOoE+NJ2+/H IZK1Rv18NH6axROeCVSvhXWO7AiHhqSxaKmx+0tBF3O7SYPleZIg6AcXRNeGPTtuW1Bb UPDGGZgarXy/XCMRnzB8h7KP0rfAnFY0R0poA7+zGX85AINSiP51ZBqO30/kra+kxESg CwEA==
X-Gm-Message-State: APjAAAWEiJ73qvt30X1sgqn67vbH1gtgX6ZVr2oLR9aAJzxR+KVATYUB Mkt58092lBrv97pqj6SYS33XMfpa0AEi8bPVpyn2ZA==
X-Google-Smtp-Source: APXvYqxMv1e708/3aSPgimpXBy17EPCgtHQFqE51FofUWInpNkDugCG9PhXnE8CiZg7Ycjz/6k/KVtvR00fbxly34sc=
X-Received: by 2002:a05:6638:73a:: with SMTP id j26mr5243473jad.116.1573147432362; Thu, 07 Nov 2019 09:23:52 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR05MB416368F6F754F6B6E0095648FA7F0@BN7PR05MB4163.namprd05.prod.outlook.com> <CABuGu1rsiK0VWXCZXqhLvbO0bULBPZD+JuQ9LqwzMr05MSnLpQ@mail.gmail.com> <CABa8R6vVRT_y_RyL6+vgi9-e4-ySbLUuQewD8kRwSv9U+8w0YQ@mail.gmail.com> <BYAPR05MB4167E31DE0CC7377CEACF1A5FA780@BYAPR05MB4167.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB4167E31DE0CC7377CEACF1A5FA780@BYAPR05MB4167.namprd05.prod.outlook.com>
From: "Kurt Andersen (b)" <kboth@drkurt.com>
Date: Thu, 7 Nov 2019 09:23:37 -0800
Message-ID: <CABuGu1qfP=PAcUZgAo9i_s7OOhU2M38VL4-Zcxpi_h3pmy-Z2Q@mail.gmail.com>
To: "Weist, Bill" <William.Weist@iqvia.com>
Cc: Brandon Long <blong@google.com>, "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/related; boundary="000000000000e2e0d30596c4ed68"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/wPtf0cQRg6rTxI98JlcbWaMXX34>
Subject: Re: [dmarc-ietf] Question regarding RFC 8617
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: Thu, 07 Nov 2019 17:23:56 -0000

Both of the cases you cited are entirely covered by ARC. If you are seeing
failures, I would be pointing the finger toward said "intermediary SMTP
system" which is modifying the message without properly affixing its own
ARC set.

--Kurt

On Thu, Nov 7, 2019 at 8:45 AM Weist, Bill <William.Weist@iqvia.com>; wrote:

> Thank you both for replying.  There are two instances where I have
> identified ARC signatures consistently failing:
>
>
>
> Case 1:  An intermediary SMTP system receives an email on behalf of a
> recipient system whereby the “from” field is required to be changed for the
> email to reply as desired by the recipient system.  (example:
> William.Weist@gmail.com rewritten to William.Weist@iqvia.com)
>
>
>
> Case 2: An Intermediary SMTP system receives an email on behalf of the
> recipient system whereby the “subject” field is required to by changed for
> the email to be categorized as desired by the recipient system. (example:
> “RE: [dmarc-ietf] Question regarding RFC 8617” modified to:  “RFC
> Correspondence: [dmarc-ietf] Question regarding RFC 8617”)
>
>
>
> As Kurt pointed out below, the ARC signature is NOT intended to be
> validated by hops >1 step away.  However, I did not think this was the case
> and that ARC was specifically supposed to validate each custodian where
> DKIM would be broken by the cases listed above.
>
>
>
> As differentiated from DKIM, the RFC reads as if ARC is designed to
> validate the “custodian” and NOT the “sender” therefore, “From” and
> “Subject” would not be as desirable as say “X-Received”,
> “X-Google-Smtp-Source”, and “X-Gm-Message-State” in the case of Brandon’s
> email to which I am replying.
>
>
>
> It is my suggestion that for ARC to be a valuable addition to DKIM, it
> needs to focus on the “custodian” and not the “sender”.
>
>
>
> Thank you both for your time and attention.
>
> -Bill
>
>
>
> *From:* Brandon Long <blong@google.com>;
> *Sent:* Wednesday, November 6, 2019 12:43 PM
> *To:* Kurt Andersen (b) <kboth@drkurt.com>;
> *Cc:* Weist, Bill <William.Weist@iqvia.com>;; dmarc@ietf.org
> *Subject:* Re: [dmarc-ietf] Question regarding RFC 8617
>
>
>
> This email originated from outside of the organization.
>
>
>
> What's more, the point of including Subject and other mutable headers is
> the same as it is for DKIM, those are the headers which are important to
> the receiver, so they should be validated.
>
> As Kurt points out, the point of ARC is to acknowledge these changes hop
> to hop, and the Arc Seal proves who did the change, the question becomes do
> you believe
>
> the person who changed it wasn't malicious.
>
>
>
> Brandon
>
>
>
> On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) <kboth@drkurt.com>; wrote:
>
> The choice of which headers are included in the signed set is strictly up
> to the domain administrators who implement the signing practices. Also, the
> AMS is only relevant for the next receiver, it is not intended to be
> validated by hops >1 step away from the domain which adds that instance so
> I don't see how mutability would matter.
>
>
>
> --Kurt Andersen
>
>
>
> On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill <William.Weist@iqvia.com>;
> wrote:
>
> DOI:  10.17487/RFC8617
>
>
>
> The inclusion of the address headers in the signature, and possibly the
> Subject, is an issue:
>
>
>
> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
> microsoft.com
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.com&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191460908&sdata=KyZ7aC4X35IcojTOEbgeDFXnOPPSHvlt8RaqH8VtXpA%3D&reserved=0>;;
> s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
> bh=;
>
>
>
> If a downstream server needs to modify either of these two values, the
> signature check fails.
>
>
>
> It is my understanding that the Authenticated Received Check signature is
> to validate the chain of possession.  As such, in my opinion, the signature
> should only include immutable references.
>
>
>
> In my opinion, there is value in NOT requiring headers to be stripped by
> downstream servers, thus maintaining the custody chain from origination to
> destination.
>
>
>
> Thank you for your time and attention,
>
>
>
> *William M. Weist*
>
> *Enterprise Architect I – Global Messaging – Mobile and Presence*
>
> CIO Team – End User Computing
>
> *[image: IQVIA logo_96dpi_100pxheight]*
>
> Learn more
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iqvia.com%2F&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191470898&sdata=w%2FI0jSRPXe2FRdp%2FgJ24EiKQO3OXBlB9ZOJjl4FVswE%3D&reserved=0>
> about IQVIA™
>
>
>
> 400 Campus Drive
>
> Collegeville, PA 19426
>
> USA
>
>
>
> O: +1 610 244 2646 <(610)%20244-2646> | M: +1 484 904 8244
> <(484)%20904-8244>
>
>
>
>
>
> ________________________________________
> *IMPORTANT* - PLEASE READ: This electronic message, including its
> attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY
> PRIVILEGED or PROTECTED information and is intended for the authorized
> recipient of the sender. If you are not the intended recipient, you are
> hereby notified that any use, disclosure, copying, or distribution of this
> message or any of the information included in it is unauthorized and
> strictly prohibited. If you have received this message in error, please
> immediately notify the sender by reply e-mail and permanently delete this
> message and its attachments, along with any copies thereof, from all
> locations received (e.g., computer, mobile device, etc.). To the extent
> permitted by law, we may monitor electronic communications for the purposes
> of ensuring compliance with our legal and regulatory obligations and
> internal policies. We may also collect email traffic headers for analyzing
> patterns of network traffic and managing client relationships. For further
> information see: https://www.iqvia.com/about-us/privacy/privacy-policy
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iqvia.com%2Fabout-us%2Fprivacy%2Fprivacy-policy&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191470898&sdata=HeMk%2BjRXLVJuYxWpQgL8g0DiHMOstcrEAjuppTXTHnc%3D&reserved=0>;..
> Thank you.
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191470898&sdata=j1TU7PWjgxQGvmjfQ4RKZGQSzvQ7IrwTtcHMnW6ZAQE%3D&reserved=0>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191480892&sdata=CvW1a5LuaUQBNVONP%2BZiX0zCRsJwvuCxb2%2FCcuQevhU%3D&reserved=0>
>
>