Subject: [dmarc-ietf] Question regarding RFC 8617

From: "Weist, Bill" <[email-masked]>
Date: Mon, 4 Nov 2019 17:17:35 +0000

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; 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
[IQVIA logo_96dpi_100pxheight]
Learn more<http://www.iqvia.com/> about IQVIA(tm)

400 Campus Drive
Collegeville, PA 19426
USA

O: +1 610 244 2646 | M: +1 484 904 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. Thank you.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 6 Nov 2019 07:36:37 -0800

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 <[email-masked]> wrote:

> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
> microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
> bh=;
>
>
>
> 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.
>
>
>
> *William M. Weist*
> *Enterprise Architect I – Global Messaging – Mobile and Presence*
>
> CIO Team – End User Computing
>
> **
>
> Learn more <http://www.iqvia.com/> about IQVIA™
>
>
>
> 400 Campus Drive
>
> Collegeville, PA 19426
>
> USA
>
>
>
> *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.
> Thank you.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Brandon Long <[email-masked]>
Date: Wed, 6 Nov 2019 09:43:22 -0800

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) <[email-masked]> wrote:

>> O: +1 610 244 2646 <(610)%20244-2646> | M: +1 484 904 8244
>> <(484)%20904-8244>
>>
>>
>>
>>
>> information see: https://www.iqvia.com/about-us/privacy/privacy-policy..
>> Thank you.
>>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 7 Nov 2019 09:23:37 -0800

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 <[email-masked]> 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:
> [email-masked] rewritten to [email-masked])
>
>
>
> 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 <[email-masked]>
> *Sent:* Wednesday, November 6, 2019 12:43 PM
> *To:* Kurt Andersen (b) <[email-masked]>
> *Cc:* Weist, Bill <[email-masked]>; [email-masked]
> *Subject:* Re: [dmarc-ietf] Question regarding RFC 8617
>
>
>
> This email originated from outside of the organization.
>
>
>
> 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
>
> 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=;
>
>
>
> 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
>
>
>
> 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.
>
> <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>
>
> <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>
>
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Nov 2019 09:28:22 -0800

> the receiver, so they should be validated.

This being a technical list, I'm going to get picky and note that DKIM 
does not 'validate' those fields.

There is a derivative data integrity benefit, between signing and 
validated, for such fields, but that is quite different from any claim 
that the contents of those fields are 'valid'.

Some signing sites have much more stringent uses of DKIM than are 
provided by the standard.  That's fine, of course, but it has nothing to 
do with the standard.  Hence any receive-side reliance on such signer 
data validation is outside the DKIM standard.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Weist, Bill" <[email-masked]>
Date: Thu, 7 Nov 2019 16:45:37 +0000

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: [email-masked] rewritten to [email-masked])

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

From: Brandon Long <[email-masked]>
Sent: Wednesday, November 6, 2019 12:43 PM
To: Kurt Andersen (b) <[email-masked]>
Cc: Weist, Bill <[email-masked]>; [email-masked]
Subject: Re: [dmarc-ietf] Question regarding RFC 8617

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) <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
DOI:  10.17487/RFC8617

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

William M. Weist
Enterprise Architect I – Global Messaging – Mobile and Presence
CIO Team – End User Computing
[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<tel:(610)%20244-2646> | M: +1 484 904 8244<tel:(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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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>

---

From: Brandon Long <[email-masked]>
Date: Thu, 7 Nov 2019 15:16:02 -0800

> data validation is outside the DKIM standard.

I should have said "covered by the signature".

And I think they are important to both the sender and receiver, your DKIM
RFC calls them "core to the message content" and so the "core of the
message is valid"... which is different than validated, of course.

For ARC, this still holds true, that AMS is analogous DKIM, and should cover
 the core of the message, and ARC allows for you to know if and between
which hops
the core of the message was modified.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Thu, 7 Nov 2019 15:45:37 -0800

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Nov 2019 16:13:07 -0800

On 11/7/2019 3:16 PM, Brandon Long wrote:
> 
> 
> On Thu, Nov 7, 2019 at 9:28 AM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

yeah.  really unfortunate language.  over the course of different DKIM 
docs, I kept finding language that needed to be /much/ better.  Only 
some of it now is.

That's not one of them, since the context was of that bit of text was 
meant to assert transit integrity rather than data 'validity'.  sigh.

At least there is some comfort that that section makes clear it's 
concern is replay protection, rather than semantic validity.

d/