Re: [dmarc-ietf] Question regarding RFC 8617

Brandon Long <blong@google.com> Thu, 07 November 2019 23:45 UTC

Return-Path: <blong@google.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 C1797120018 for <dmarc@ietfa.amsl.com>; Thu, 7 Nov 2019 15:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.299
X-Spam-Level:
X-Spam-Status: No, score=-17.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WBFSYGWYvrDG for <dmarc@ietfa.amsl.com>; Thu, 7 Nov 2019 15:45:52 -0800 (PST)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 913281200C4 for <dmarc@ietf.org>; Thu, 7 Nov 2019 15:45:52 -0800 (PST)
Received: by mail-ua1-x931.google.com with SMTP id k11so1176433ual.10 for <dmarc@ietf.org>; Thu, 07 Nov 2019 15:45:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vl8D8LJ+mJ6sTTukIDxoWLzVG8uGFBLJrxChrlqC7CY=; b=A3juhuJXWAbEncu39op1kg3pSrrKrkC2uJ5m/bwymkV1XwbUMz/xvXUoUnVGnwb8II sRhmPo3hBvV8ameAFS7KCWJBDgKFjkSl/B7n9jdEDUksfhkKDdelvjXZkzh7pN9PtQVW I0yYcmpbA0v668HkwwxQFr+I1W30zaOByqbz1/8FWGSfD7hqM69rwqA6yUtpFGfOvGas WvLlG35h58JpW72YeZ3G5JX3TMfYD/Q8Hq1FenjCQ6QOxSK3Umsf2gx2TZhlm/+SPcOM T/H0qCRkSIlm3bPbYGxxPGXvTKSi4aXImCuC5UIsBsKZJ87XzEfxu7l3ioWPJZklRbY1 DkDg==
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=Vl8D8LJ+mJ6sTTukIDxoWLzVG8uGFBLJrxChrlqC7CY=; b=gLMERBtRKmoS3cHX5pFTuH6SnjQwhHIb5rVbP3Paa0T0mY9MzxA6vZnVJWpmGInqai r0il40uQKMDkAyuy/H+iJyeBQ69iytGCuwmt7BA+nBqIvQuL1dRlkSkhioHLZ9oatblz PxwNuzW7DDFb7N677cLCO2rBxNwgFxm9/LjpZhmQqAS5Tlv0maXqXlXxx/U5xoWG2GEV W5ZlKjmLV+3VJ6k5FWZ7JA6ddiidvyZEAsPIlgJxvAo8DgRtL178So2oSo3tt37Y9oVd c1wOnsHeUtq9RBkl920t0JXpQuVnXs4/jluGvu32kUOlXzvKQ4846YpafidhJ0rPsLyv vH6A==
X-Gm-Message-State: APjAAAV18VSN6EFt5C2UwCMn2CRKdasrDmw8XtmIcsU3h8nJqmCCDLyL ZFS35lUlO56pB5V01ftpuyMHhWUi+wXDqexqJ61YD8fGWQ==
X-Google-Smtp-Source: APXvYqwnTIloGo1yJOnrMV+NJf81LLZYbqCy7S/iAcLvFAjWS3aTduwHKbf+nXXJIigmVguWOZq6s/YWgZK0o/S/kRk=
X-Received: by 2002:ab0:55c8:: with SMTP id w8mr4116682uaa.66.1573170350672; Thu, 07 Nov 2019 15:45:50 -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: Brandon Long <blong@google.com>
Date: Thu, 7 Nov 2019 15:45:37 -0800
Message-ID: <CABa8R6sqARRz8rbk22zRmtzF5aq7sm9Rb0df6UP98HUqD0=gOw@mail.gmail.com>
To: "Weist, Bill" <William.Weist@iqvia.com>
Cc: "Kurt Andersen (b)" <kboth@drkurt.com>, "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/related; boundary="000000000000ed10f80596ca432d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/xmx2yJFCRuUExfQgQdpjC5CGHVI>
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 23:45:56 -0000

Yes, its for checking whether a custodian made changes, but the changes its
checking for are the core of the message (to use the DKIM wording), the
same as DKIM.

If the core of the message was unchanged, then ARC is unnecessary.  The
utility of ARC is to pinpoint where the core was changed, so the receiver
can make a
judgement as to how to handle the message.

Brandon

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>
>
>