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, 07 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> > >
- [dmarc-ietf] Question regarding RFC 8617 Weist, Bill
- Re: [dmarc-ietf] Question regarding RFC 8617 Kurt Andersen (b)
- Re: [dmarc-ietf] Question regarding RFC 8617 Brandon Long
- Re: [dmarc-ietf] Question regarding RFC 8617 Kurt Andersen (b)
- Re: [dmarc-ietf] Question regarding RFC 8617 Dave Crocker
- Re: [dmarc-ietf] Question regarding RFC 8617 Weist, Bill
- Re: [dmarc-ietf] Question regarding RFC 8617 Brandon Long
- Re: [dmarc-ietf] Question regarding RFC 8617 Brandon Long
- Re: [dmarc-ietf] Question regarding RFC 8617 Dave Crocker