Subject: Re: [dmarc-ietf] ARC protocol-15 posted

From: Jim Fenton <[email-masked]>
Date: Mon, 9 Jul 2018 15:01:21 -0700

On 6/24/18 9:27 PM, Kurt Andersen wrote:
> I've now posted draft 15 of the ARC protocol. It should be ready for 
> last call - please review with that in mind. Note that the XML was a 
> little wacky in the Implementation Status section. I'll fix that 
> formatting in the next rev.

I'm very late in reviewing the ARC protocol, and I apologize for that, 
as well as for not keeping up with the discussions on this list. So 
please consider the below to be a "external review" -- I suspect that 
other reviewers outside the WG will have many of the same 
questions/comments.

Substantive issues:

General: I see lots of references to "authentication state", beginning 
with two references in the abstract, but I don't see the term defined 
anywhere. Perhaps add to the general concepts (section 2).

2.1: "modify message content": Might not be clear whether this includes 
the message header or only the body.

4. Protocol elements: It's not immediately evident to me why we need new 
header fields here rather than extensions to existing header fields:

- AAR is basically an Authentication-Results with an added instance tag; 
why not just do that?
- AMS says that it's basically a DKIM-Signature header field with an 
instance tag and no version. Why not just add an optional instance tag 
to DKIM-Signature? But I do see a semantic difference that isn't listed 
in 4.1.2. The order of inclusion of "instanced" header fields is based 
on the instance number, not simply bottom-up as in DKIM. I can see why 
this is done, since header field ordering isn't guaranteed to be 
preserved. But I haven't found anything that fully orders the header 
fields in this case; do the "instanced" header fields go before the 
others, after the others, or some other way? Note that even if distinct 
header field names are used, the h= value in the DKIM-Signature 
specifies what's included, not the order.
- AS: I'm having trouble understanding what this is for. Why do we need 
another layer of signature on top of that in the AMS?

In the ABNF for the AMS header field (and others), where is "instance" 
defined?

"Authentication-Results header fields MUST NOT be included in AMS 
signatures": This seems harsh, especially since Section 5 of 7601bis 
(cited, also RFC 7601) make inclusion of Authentication-Results a MAY. 
Is there a reason for the much more restrictive wording here?

4.2.1: Instance tag value range: Why 50? That seems like an arbitrary 
choice; is there some other basis for it?
Informational paragraph: Since the cited DCRUP work has passed IESG 
approval (just got a state update to "Waiting on RFC Editor" as I type 
this), it sounds like the ARC-MULTI stuff ought to be here rather than 
in a separate document. But there are other reasons for having multiple 
DKIM-Signatures on a message, such as key rotation. ARC needs to be able 
to deal with this; perhaps it's all covered in ARC-MULTI which I haven't 
read yet.

5.1.1: As noted above, needs to completely specify the order in which 
header fields are supplied to the hash function (both ARC and non-ARC 
header fields).

5.2 step 5 et seq: Are some of the following steps sub-steps to 5 (done 
repeatedly for each ARC set)? There's a colon there but not sure how far 
it goes.

5.2.2 conflicts with the second to last paragraph in 5.2 that a message 
with a failing ARC MUST be treated the same as one with no ARC.

9.1 is not a security consideration, or at least it's not in expressed 
in terms of how an attacker might exploit ARC to cause problems with 
header size.

10. I don't see any other reference to header.s so I'm not sure what the 
bracketed comment at the beginning is referring to.

10.2 I'm not clear on why there is an IANA consideration for the "s" 
signature tag (perhaps this is the header.s above).

13.2 Not clear to me why previous revisions of this draft are included 
as informative references. ARC-MULTI (IMO) should be included in this 
draft. ENHANCED-STATUS looks like a normative reference to me. Some of 
the references to 7601bis might also be normative; can these be changed 
to 7601 (non-bis)?

Appendix B: It would be really, really helpful to have at least one 
example here.

=====
Nits:

1. paragraph 3, "each individual processing results" -> "each individual 
processing result"

3. paragraph 3, "is directly relevant" -> "are directly relevant"

3.5 (imported ABNF tokens) looks like it would go better being adjacent 
to the imported terms in section 3.

4.1.2 second bullet "AMS header" -> "AMS header field"

4.1.2 first bullet of second group "should" -> "SHOULD"

4.1.3 second bullet "Section" is repeated

4.1.3 fifth bullet "h" header -> "h" tag

Might want to run idnits on the draft; it especially doesn't like the 
URIs in 13.3 (perhaps just include needed URIs inline in the text).

=====

-Jim

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 9 Jul 2018 19:28:21 -0700

On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton <[email-masked]> wrote:

>> I've now posted draft 15 of the ARC protocol. It should be ready for last
>> call - please review with that in mind. Note that the XML was a little
>> wacky in the Implementation Status section. I'll fix that formatting in the
>> next rev.
>>
>
> I'm very late in reviewing the ARC protocol, and I apologize for that, as
> well as for not keeping up with the discussions on this list. So please
> consider the below to be a "external review" -- I suspect that other
> reviewers outside the WG will have many of the same questions/comments.
>

Terrific - thanks for going through it. Responses to your questions inline
below.

> anywhere. Perhaps add to the general concepts (section 2).

While I understand your question, is the combination of the two terms not
self-evident? Is it something that needs to be further expanded upon? If
so, can you suggest some language which might have satisfied your
uncertainty?

> the message header or only the body.

Intended in the most broad sense: header, body, or both. We can add a
parenthetical comment to clarify.

> - AAR is basically an Authentication-Results with an added instance tag;

Because A-R is ephemeral and, per 7601 both can and should be deleted at
will.

> instance tag and no version. Why not just add an optional instance tag to
> DKIM-Signature? But I do see a semantic difference that isn't listed in
> 4.1.2. The order of inclusion of "instanced" header fields is based on the
> instance number, not simply bottom-up as in DKIM. I can see why this is
> done, since header field ordering isn't guaranteed to be preserved. But I
> haven't found anything that fully orders the header fields in this case; do
> the "instanced" header fields go before the others, after the others, or
> some other way? Note that even if distinct header field names are used, the
> h= value in the DKIM-Signature specifies what's included, not the order.
>

The ordering is clearly defined - when "h=" cites (using abbreviated header
names) "DKIM:DKIM:Date:AAR:AMS:AAR:AMS:AAR:AMS" that would be
AAR[1]:AMS[1]:AAR[2]:AMS[2]" per the definition.

> another layer of signature on top of that in the AMS?

Because the AS, signing only the ARC chain headers, provides a less
fragile/more resilient mechanism for chain continuity. By scoping to just
the ARC chain, we expect less collateral breakage than any signature which
covers arbitrary headers and body.

> In the ABNF for the AMS header field (and others), where is "instance"

instance is defined in section 3.6

> (cited, also RFC 7601) make inclusion of Authentication-Results a MAY. Is
> there a reason for the much more restrictive wording here?
>

Yes, and it goes back to the "ephemerality" of A-R headers. We want to
avoid signing any content which downstream handlers can arbitrarily delete.

> choice; is there some other basis for it?

The choice of 50 is somewhat arbitrary, in that it could equally well be 49
or 75. Early versions specified values up to 1024 would be legal, but since
the working group felt that handling chains over 10 ADMDs to be fairly
unlikely, we thought that a 5x margin should be sufficient without allowing
completely ridiculous header bloat.

> this), it sounds like the ARC-MULTI stuff ought to be here rather than in a
> separate document. But there are other reasons for having multiple
> DKIM-Signatures on a message, such as key rotation. ARC needs to be able to
> deal with this; perhaps it's all covered in ARC-MULTI which I haven't read
> yet.
>

Yes, it's the ARC-MULTI doc. We split them so that we can get the basic
protocol through WGLC before wrestling through multiple algorithms and
algorithm migration.

> header fields are supplied to the hash function (both ARC and non-ARC

Will review the text to clarify.

> repeatedly for each ARC set)? There's a colon there but not sure how far it
> goes.
>

The colon is a typo, should be a period.

> with a failing ARC MUST be treated the same as one with no ARC.

Not really, but the process is not clearly spelled out. If an incoming
message fails to have a passing DMARC result and the ARC chain does not
provide sufficient information (or trusted information) to mitigate a
resulting "REJECT" policy, then a message can be REJECTed during the SMTP
transaction with this extended result. No ARC chain would have the same
result as a failing one in such a case.

> 9.1 is not a security consideration, or at least it's not in expressed in
> terms of how an attacker might exploit ARC to cause problems with header
> size.
>

I agree that this is not really a security issue - but it is a potential
operational one. Where should this caution be moved do?

> signature tag (perhaps this is the header.s above).

Yes, the "s" tag is the "header.s" ptype when more fully specified. I'll
clarify the note to the editor.

> 13.2 Not clear to me why previous revisions of this draft are included as
> informative references. ARC-MULTI (IMO) should be included in this draft.
> ENHANCED-STATUS looks like a normative reference to me. Some of the
> references to 7601bis might also be normative; can these be changed to 7601
> (non-bis)?
>

The previous versions are cited because some of the implementations listed
in section 12 were built to earlier versions and have not necessarily been
vetted against the current version. With the removal of section 12 upon
publication, those earlier versions can also be dropped.

The references to 7601bis will be normative, but only once the updated
document number is issued. I don't think that we can cite a "bis" as a
normative reference.

> Appendix B: It would be really, really helpful to have at least one

Yes, planning to...up until version -13, we had carried some very old
examples which were now causing more confusion as people looked at the
examples rather than the text.

> Nits:

<eliding here - updates noted for the next version of the spec>

Thanks again!

--Kurt

---

From: Jim Fenton <[email-masked]>
Date: Tue, 10 Jul 2018 12:13:01 -0700

On 7/9/18 7:28 PM, Kurt Andersen (b) wrote:

> On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Substantive issues:
>
>     General: I see lots of references to "authentication state",
>     beginning with two references in the abstract, but I don't see the
>     term defined anywhere. Perhaps add to the general concepts
>     (section 2).
>
>
> While I understand your question, is the combination of the two terms 
> not self-evident? Is it something that needs to be further expanded 
> upon? If so, can you suggest some language which might have satisfied 
> your uncertainty?

I wasn't clear on what all is included in authentication state. Is it 
just the question of whether the message currently passes an 
authentication check, or whether authentication is asserted by a third 
party through an ARC seal?

While I think of it, I'm wondering if ARC covers message authentication 
via SPF or DKIM only. Presumably only the first hop from the originating 
ADMD would pass SPF, and then DKIM is used after that? It might be good 
to mention relationship with non-DKIM authentication somewhere.
>
>     4. Protocol elements: It's not immediately evident to me why we
>     need new header fields here rather than extensions to existing
>     header fields:
>
>     - AAR is basically an Authentication-Results with an added
>     instance tag; why not just do that?
>
>
> Because A-R is ephemeral and, per 7601 both can and should be deleted 
> at will.

I'm fine with deleting clearly fraudulent A-R (spoofed A-R claiming to 
be from the receiving MTA's own ADMD). But IMO it's really unfortunate 
that 7601 is so free about (and even encourages) deleting A-R header 
fields, because in this case it means that they need to be, essentially, 
duplicated for ARC, with the message header bloat that entails.

Is it possible for this spec to update 7601 by saying something like, 
"MTAs implementing ARC MUST NOT delete A-R header fields containing 
instance tags"? I need to think more about message paths containing a 
mixture of ARC-aware and ARC-unaware MTAs and whether there are any 
issues there, and would need to consider this as well.

>     - AMS says that it's basically a DKIM-Signature header field with
>     an instance tag and no version. Why not just add an optional
>     instance tag to DKIM-Signature? But I do see a semantic difference
>     that isn't listed in 4.1.2. The order of inclusion of "instanced"
>     header fields is based on the instance number, not simply
>     bottom-up as in DKIM. I can see why this is done, since header
>     field ordering isn't guaranteed to be preserved. But I haven't
>     found anything that fully orders the header fields in this case;
>     do the "instanced" header fields go before the others, after the
>     others, or some other way? Note that even if distinct header field
>     names are used, the h= value in the DKIM-Signature specifies
>     what's included, not the order.
>
>
> The ordering is clearly defined - when "h=" cites (using abbreviated 
> header names) "DKIM:DKIM:Date:AAR:AMS:AAR:AMS:AAR:AMS" that would be 

OK; my recollection of how the DKIM h= tag/value works was incorrect. So 
the first DKIM picks up the bottommost signature and the second one 
picks up the second from the bottom, but the selection of AAR and AMS is 
based on instance number, not position. That's not ambiguous, but it 
would be good to point the header field ordering out as an additional 
(fourth) difference between AMS and DKIM-Signature in 4.1.2.
>
>     - AS: I'm having trouble understanding what this is for. Why do we
>     need another layer of signature on top of that in the AMS?
>
>
> fragile/more resilient mechanism for chain continuity. By scoping to 
> just the ARC chain, we expect less collateral breakage than any 
> signature which covers arbitrary headers and body.

The point of signing the body in DKIM was to make sure that there was no 
opportunity to splice a different body onto a validly signed message. 
This was considered important when we discussed the l= (length) 
tag/value on DKIM signatures, because there was concern that an attacker 
could append content to a message with a valid signature.

My concern with this is that since AS isn't signing the body but is 
being depended upon for message handling decisions, this might be 
exploited by an attacker. This needs, at a minimum, to be a security 
consideration.
>
>     In the ABNF for the AMS header field (and others), where is
>     "instance" defined?
>
>

Thanks; don't know how I missed it. It uses i=, which is already a DKIM 
tag. In describing the differences between AMS and DKIM-Signature, 4.1.2 
should prohibit the DKIM use of i= in AMS. Or it should use a different 
tag letter.
>     signatures": This seems harsh, especially since Section 5 of
>     7601bis (cited, also RFC 7601) make inclusion of
>     Authentication-Results a MAY. Is there a reason for the much more
>     restrictive wording here?
>
>

OK; see above comment re 7601.
>
>     4.2.1: Instance tag value range: Why 50? That seems like an
>     arbitrary choice; is there some other basis for it?
>
>
> The choice of 50 is somewhat arbitrary, in that it could equally well 
> be 49 or 75. Early versions specified values up to 1024 would be 
> legal, but since the working group felt that handling chains over 10 
> ADMDs to be fairly unlikely, we thought that a 5x margin should be 
> sufficient without allowing completely ridiculous header bloat.

Makes sense. Maybe include something informational to that effect?
>
>     Informational paragraph: Since the cited DCRUP work has passed
>     IESG approval (just got a state update to "Waiting on RFC Editor"
>     as I type this), it sounds like the ARC-MULTI stuff ought to be
>     here rather than in a separate document. But there are other
>     reasons for having multiple DKIM-Signatures on a message, such as
>     key rotation. ARC needs to be able to deal with this; perhaps it's
>     all covered in ARC-MULTI which I haven't read yet.
>
>
> Yes, it's the ARC-MULTI doc. We split them so that we can get the 
> basic protocol through WGLC before wrestling through multiple 
> algorithms and algorithm migration.

I disagree with the split. I don't think this spec is complete without 
guidance on how to handle multiply-signed messages, which will become 
sharply more prevalent with the DCRUP work.

>     5.1.1: As noted above, needs to completely specify the order in
>     which header fields are supplied to the hash function (both ARC
>     and non-ARC header fields).
>
>
>     5.2 step 5 et seq: Are some of the following steps sub-steps to 5
>     (done repeatedly for each ARC set)? There's a colon there but not
>     sure how far it goes.
>
>

Please double-check this; step 6 at least reads like it's something done 
iteratively as introduced in step 5.
>
>     5.2.2 conflicts with the second to last paragraph in 5.2 that a
>     message with a failing ARC MUST be treated the same as one with no
>     ARC.
>
>
> message fails to have a passing DMARC result and the ARC chain does 
> not provide sufficient information (or trusted information) to 
> mitigate a resulting "REJECT" policy, then a message can be REJECTed 
> during the SMTP transaction with this extended result. No ARC chain 
> would have the same result as a failing one in such a case.

5.2.2 refers to an ARC validation failure, not a DMARC policy action. If 
a rejection occurs, it's DMARC that is doing that, not ARC. Perhaps 
there will need to be an update to DMARC to describe how it processes 
ARC results?
>
>     9.1 is not a security consideration, or at least it's not in
>     expressed in terms of how an attacker might exploit ARC to cause
>     problems with header size.
>
>
> I agree that this is not really a security issue - but it is a 
> potential operational one. Where should this caution be moved do?

I'm not sure there is a defined place. Perhaps an informational note in 
4.3 where it's describing the chain as a whole would be an appropriate 
place for this.

>     10. I don't see any other reference to header.s so I'm not sure
>     what the bracketed comment at the beginning is referring to.
>
>     10.2 I'm not clear on why there is an IANA consideration for the
>     "s" signature tag (perhaps this is the header.s above).
>
>
> Yes, the "s" tag is the "header.s" ptype when more fully specified. 
> I'll clarify the note to the editor.
>
>     13.2 Not clear to me why previous revisions of this draft are
>     included as informative references. ARC-MULTI (IMO) should be
>     included in this draft. ENHANCED-STATUS looks like a normative
>     reference to me. Some of the references to 7601bis might also be
>     normative; can these be changed to 7601 (non-bis)?
>
>
> The previous versions are cited because some of the implementations 
> listed in section 12 were built to earlier versions and have not 
> necessarily been vetted against the current version. With the removal 
> of section 12 upon publication, those earlier versions can also be 
> dropped.
>

At publication, you shouldn't cite an Internet Draft at all since it 
will expire. Whether references are normative or informative doesn't 
depend on the status of the document, but on the nature of the 
reference. I'm under the impression that this document is ahead of 
7601bis for publication. If it depends on things that are new in 
7601bis, then it will need to wait for 7601bis to be published. 
Otherwise, suggest you make the references to 7601 instead.
>
>     Appendix B: It would be really, really helpful to have at least
>     one example here.
>
>

Making sure that the example(s) is/are correct is an important thing to 
have reviewed carefully. This would be great to have before Last Call.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jul 2018 12:43:11 -0700

On Tue, Jul 10, 2018 at 12:13 PM, Jim Fenton <[email-masked]> wrote:

> I wasn't clear on what all is included in authentication state. Is it just
> the question of whether the message currently passes an authentication
> check, or whether authentication is asserted by a third party through an
> ARC seal?
>

Since this is a general question, a general reply: What ARC seeks to do is
capture what the sealer saw in terms of authentication results at the time
it handled the message, and attach those results to the message in a way
that they cannot later be falsified.  That collection of results coupled
with the identity of the sealer is what I think is meant by "authentication
state".

While I think of it, I'm wondering if ARC covers message authentication via
> SPF or DKIM only. Presumably only the first hop from the originating ADMD
> would pass SPF, and then DKIM is used after that? It might be good to
> mention relationship with non-DKIM authentication somewhere.
>

I think ARC is agnostic about particular methods.  It just records all of
that state and passes it forward.  It's up to the receiver (mainly a DMARC
processor) to decide what to do with it.

> I'm fine with deleting clearly fraudulent A-R (spoofed A-R claiming to be
> from the receiving MTA's own ADMD). But IMO it's really unfortunate that
> 7601 is so free about (and even encourages) deleting A-R header fields,
> because in this case it means that they need to be, essentially, duplicated
> for ARC, with the message header bloat that entails.
>

RFC7601 doesn't require or encourage deletion of A-R fields in general.
(The strongest word is "could".)  If it's valid and possibly useful
downstream, you can certainly keep it.  It only says you have to delete
stuff that's clearly a forgery.

> mixture of ARC-aware and ARC-unaware MTAs and whether there are any issues
> there, and would need to consider this as well.
>

It could.

> opportunity to splice a different body onto a validly signed message. This
> was considered important when we discussed the l= (length) tag/value on
> DKIM signatures, because there was concern that an attacker could append
> content to a message with a valid signature.
>
> My concern with this is that since AS isn't signing the body but is being
> depended upon for message handling decisions, this might be exploited by an
> attacker. This needs, at a minimum, to be a security consideration.
>

AMS is basically the same as DKIM-Signature, and so it covers body
modifications.  When you verify the seal, you must also verify the latest
AMS, which in turn means the seal is invalidated as soon as someone changes
the content.

> 5.2.2 refers to an ARC validation failure, not a DMARC policy action. If a
> rejection occurs, it's DMARC that is doing that, not ARC. Perhaps there
> will need to be an update to DMARC to describe how it processes ARC results?
>

I agree that this needs to be said somewhere.  One of the work items of
this WG is a standards track update to DMARC, so it could be punted to
there as well.

> 4.3 where it's describing the chain as a whole would be an appropriate

I disagree.  If I can cause your MTA to crash because of oversized header
fields, that's at least a denial of service attack.  If I can cause your
filter to crash because of oversized header fields and your MTA fails open,
I can bypass whatever protections the filter offers.

> clarify the note to the editor.
The formatting in there is broken.  It'll be easier to see what's going on
when that gets fixed.  But still, something needs to register "header.s".
If these two documents go to the editor together, we'll jsut have to pick
one to contain the registration and remove it from the other one.

> At publication, you shouldn't cite an Internet Draft at all since it will
> expire. Whether references are normative or informative doesn't depend on
> the status of the document, but on the nature of the reference. I'm under
> the impression that this document is ahead of 7601bis for publication. If
> it depends on things that are new in 7601bis, then it will need to wait for
> 7601bis to be published. Otherwise, suggest you make the references to 7601
> instead.
>

I disagree.  I've had RFCs published that reference in-progress drafts, in
one case one that never got published.   But in this case, they would just
hold this until 7601bis was also ready, and publish them as a cluster.

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Tue, 10 Jul 2018 13:24:25 -0700

On 7/10/18 12:43 PM, Murray S. Kucherawy wrote:
> RFC7601 doesn't require or encourage deletion of A-R fields in 
> general.  (The strongest word is "could".)  If it's valid and possibly 
> useful downstream, you can certainly keep it.  It only says you have 
> to delete stuff that's clearly a forgery.

I didn't go back and check the wording used in 7601 obviously. I was 
inferring from the language in 4.1.2, "are likely to be deleted".
>
>>         - AS: I'm having trouble understanding what this is for. Why
>>         do we need another layer of signature on top of that in the AMS?
>>
>>
>>     Because the AS, signing only the ARC chain headers, provides a
>>     less fragile/more resilient mechanism for chain continuity. By
>>     scoping to just the ARC chain, we expect less collateral breakage
>>     than any signature which covers arbitrary headers and body.
>
>     The point of signing the body in DKIM was to make sure that there
>     was no opportunity to splice a different body onto a validly
>     signed message. This was considered important when we discussed
>     the l= (length) tag/value on DKIM signatures, because there was
>     concern that an attacker could append content to a message with a
>     valid signature.
>
>     My concern with this is that since AS isn't signing the body but
>     is being depended upon for message handling decisions, this might
>     be exploited by an attacker. This needs, at a minimum, to be a
>     security consideration.
>
>
> modifications.  When you verify the seal, you must also verify the 
> latest AMS, which in turn means the seal is invalidated as soon as 
> someone changes the content.

Which goes back to my original question. If you need to check the AMS 
anyway, what additional purpose does the AS serve?

>>         expressed in terms of how an attacker might exploit ARC to
>>         cause problems with header size.
>>
>>
>     I'm not sure there is a defined place. Perhaps an informational
>     note in 4.3 where it's describing the chain as a whole would be an
>     appropriate place for this.
>
>
> I disagree.  If I can cause your MTA to crash because of oversized 
> header fields, that's at least a denial of service attack.  If I can 
> cause your filter to crash because of oversized header fields and your 
> MTA fails open, I can bypass whatever protections the filter offers.

In that case, I'm fine if this is expressed in terms of a security 
threat. But any ARC-specific nature to this threat is a marginal case; 
an attacker could do the same in most cases by just adding lots of 
garbage header fields.

>>         included in this draft. ENHANCED-STATUS looks like a
>>         normative reference to me. Some of the references to 7601bis
>>         might also be normative; can these be changed to 7601 (non-bis)?
>>
>>
>>     The previous versions are cited because some of the
>>     implementations listed in section 12 were built to earlier
>>     versions and have not necessarily been vetted against the current
>>     version. With the removal of section 12 upon publication, those
>>     earlier versions can also be dropped.
>>
>>     The references to 7601bis will be normative, but only once the
>>     updated document number is issued. I don't think that we can cite
>>     a "bis" as a normative reference.
>
>     At publication, you shouldn't cite an Internet Draft at all since
>     it will expire. Whether references are normative or informative
>     doesn't depend on the status of the document, but on the nature of
>     the reference. I'm under the impression that this document is
>     ahead of 7601bis for publication. If it depends on things that are
>     new in 7601bis, then it will need to wait for 7601bis to be
>     published. Otherwise, suggest you make the references to 7601 instead.
>
>
> I disagree.  I've had RFCs published that reference in-progress 
> drafts, in one case one that never got published.   But in this case, 
> they would just hold this until 7601bis was also ready, and publish 
> them as a cluster.

OK, it's possible that this has been done. But the important question 
is, does this draft need to wait for 7602bis to be published?

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jul 2018 22:48:14 -0700

> anyway, what additional purpose does the AS serve?

It's an interesting question.  I imagine it's similar in nature to the fact
that the crypto part of a DKIM-Signature will still pass for a message with
a modified body; you have to then check that "bh=" matches the current
content before you can truly assert that the signature is valid.

> In that case, I'm fine if this is expressed in terms of a security threat.
> But any ARC-specific nature to this threat is a marginal case; an attacker
> could do the same in most cases by just adding lots of garbage header
> fields.
>

True, but I think the nature of the beast here is that this is a
non-garbage addition to the email infrastructure that will certainly bloat
headers, and participants (and maybe even non-participants) need to be able
to deal with it.

OK, it's possible that this has been done. But the important question is,
> does this draft need to wait for 7602bis to be published?
>

This draft, as I recall, is trying to register some things into the
authentication method registries that the prose of 7601 didn't allow.  So,
yes.  I had thought that we planned to do them as a cluster anyway, and
that 7601bis was ready for WGLC ahead of this one, but I've forgotten where
we are with it now.

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 Jul 2018 04:41:58 -0700

On Tue, Jul 10, 2018 at 10:48 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> It's an interesting question.  I imagine it's similar in nature to the
> fact that the crypto part of a DKIM-Signature will still pass for a message
> with a modified body; you have to then check that "bh=" matches the current

I think that there is a bit of a difference here and terminology is not
being used precisely. The "seal" (AS) is not invalidated when someone
changes the content.  The "signature" (AMS) is. The "seal" (aka AS) remains
valid as long as someone doesn't tamper with the chain (consisting of the
triplet ARC header fields). That allows intermediaries to change the
content and then attest to their changes within the scope of a still valid
chain.

AMS (at least the most recent one) tells you about the general headers
(covered by the signature) and the body. AS is used to string the chain
together and avoid having modifications break the chain.

--Kurt

---

From: Martijn van der Lee <[email-masked]>
Date: Wed, 11 Jul 2018 17:19:19 +0200

Hi all,

In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states
to include the ARC Set currently being added.
However, the signature cannot include the current ARC-Seal header, as it's
full contents are not yet known at the time (for obvious reasons).
Should the current ARC-Seal be excluded from the hash or should some part
of it be included?
I'm assuming the former, but regardless I can find no text to make this
explicit.
Is such text missing or am I simply overlooking it?

-- 
Best regards,

Martijn van der Lee
Software developer

DMARC Analyzer - Trusted. Email. Delivered.

Stationsplein 12 | 1211 EX | Hilversum | The Netherlands
www.dmarcanalyzer.com | +31 (0) 85 13 00 788

We are accredited on security and privacy by the DDMA Privacy Authority.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jul 2018 08:29:18 -0700

> Is such text missing or am I simply overlooking it?

If there's a question here, then there's probably room for improvement in
the text.

The way I read this and implemented it, the AMS and AAR are fully generated
before the AS is, so you have the entire ARC Set except for the "b=" part
of the AS available, and that's what gets fed to the hash function.  It's
the same way DKIM works, really.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Wed, 11 Jul 2018 10:11:59 -0700

On Wed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> martijn=[email-masked]
> <martijn=[email-masked]..org>> wrote:
>
>> In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text
>> states to include the ARC Set currently being added.
>> However, the signature cannot include the current ARC-Seal header, as
>> it's full contents are not yet known at the time (for obvious reasons).
> The way I read this and implemented it, the AMS and AAR are fully
> generated before the AS is, so you have the entire ARC Set except for the
> "b=" part of the AS available, and that's what gets fed to the hash
> function.  It's the same way DKIM works, really.
>

Yes, this is the intention. 5.1.1 specifically refers to 6376 section 3.7
which explains this behavior. This was done as a reference so that if
DKIM's mechanism changed, ARC would inherit it.

For the working group: is this still unclear, and perhaps some
non-normative text required in order to avoid confusion but not cause drift
between ARC and DKIM?

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 Jul 2018 10:12:41 -0700

> function.  It's the same way DKIM works, really.

That is correct. The whole ARC set with a blank "b=" value is hashed.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Wed, 11 Jul 2018 10:28:49 -0700

> together and avoid having modifications break the chain.

Yes, and to go one step further, there are basically three scenarios that
make the differences and value clear:

1) The latest AMS validates and all the AS's validate

==> You have an intact and valid ARC chain and can use it to influence a
local policy decision if needed

2) The latest AMS does not validate but all the AS's validate

==> You have an intact ARC chain, which you can use to localize the problem
in the chain (either an entity that doesn't sign, or does so improperly, or
between which hops a malicious actor inserted themselves, especially if you
have the oldest_hop value from intermediaries)

3) Some of the AS's don't validate

==> The chain has been tampered with and you can't trust any information
from it

Especially in a world where not everyone is using ARC, scenario 2 above
lets us as an industry identify actors who need to properly deploy ARC, and
gives us further insight into attacks we might not otherwise see.

But to circle back to Jim's original question about the value of the ARC
Seal, this has also been discussed at length in this working group, and has
probably been one of the largest technical points of contention: i.e. how
much value does it really add, for whom, and is it truly needed? Warning,
here be demons:
https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ

I believe where working group discussion ended up was that there were
strong arguments on either side, and no consensus was in sight, but there
was strong agreement that data from the experiment would clearly show if
the ARC Seal added any value beyond just the AMS, so it was left in with a
strong call out as an issue that needs resolution in section 11.3.1.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Jul 2018 11:34:17 -0700

On 7/11/18 10:28 AM, Seth Blank wrote:
>
> But to circle back to Jim's original question about the value of the 
> ARC Seal, this has also been discussed at length in this working 
> group, and has probably been one of the largest technical points of 
> contention: i.e. how much value does it really add, for whom, and is 
> it truly needed? Warning, here be demons: 
Thanks for the pointer to the 'demons'; lots there for me to absorb. 
I'll try to do that before burdening the list further on this topic.

If anyone wants to discuss any of this informally in Montreal, I'll be 
there all week. I guess the WG timeslot has been given to 'extra', and 
this is more than would fit in a 1-hour timeslot anyway.

-Jim

---

From: Brandon Long <[email-masked]>
Date: Wed, 11 Jul 2018 17:15:06 -0700

> inferring from the language in 4.1.2, "are likely to be deleted".

Right, basically an ADMD right now has to delete any existing A-R field
that claims to be the ADMD in order to prevent forgery.  If you added it to
the signature and added an instance variable, you don't need to do that
anymore, but you may still run afoul of other software that is deleting
them.

DKIM-Signatures are also sometimes removed from messages (mailing lists
often do this), and there are also MTAs which incorrectly make assumptions
about how DKIM-Signature failure means (the RFC says a failed
DKIM-Signature should be treated as if it's not there, but that's not what
we're seeing in practice).  Earlier instances of the AMS are expected to
fail if the message content is changed and for that to be fine.

We did spend a bunch of time, maybe before it even came to the IETF,
exploring whether we could do this without having a separate set of header
fields, and we decided no.

Brandon

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Jul 2018 17:38:16 -0700

On 7/11/18 5:15 PM, Brandon Long wrote:
> DKIM-Signatures are also sometimes removed from messages (mailing 
> lists often do this), and there are also MTAs which incorrectly make 
> assumptions about how DKIM-Signature failure means (the RFC says a 
> failed DKIM-Signature should be treated as if it's not there, but 
> that's not what we're seeing in practice).  Earlier instances of the 
> AMS are expected to fail if the message content is changed and for 
> that to be fine.
>
> exploring whether we could do this without having a separate set of 
> header fields, and we decided no.

So essentially we're creating a bunch of header bloat (creating 
duplicate header fields with different names where that could be 
avoided) because there are some MTAs that did not follow the 
specifications before. That makes me unhappy, but what matters here is 
not the behavior of all MTAs, it's the behavior of MTAs implementing ARC 
(that include instance number tag/value). If there's an MTA in the 
middle that deletes DKIM-Signature, it's not implementing ARC and the 
chain is broken.

Small reminiscence (feel free to ignore this): Back when we were merging 
DomainKeys and IIM to create DKIM, one of the design decisions was 
whether to publish the public key in DNS (ala DomainKeys) or to include 
it in the signature header field and put a fingerprint in DNS (ala IIM). 
The decision was made when a large mail service provider calculated how 
much more storage they would have to buy in the latter case (because of 
the larger header field). While that was ~14 years ago and storage is 
cheaper now, we're talking about a lot more space than just a public key.

-Jim

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 Jul 2018 18:23:47 -0700

On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton <[email-masked]> wrote:

>
> So essentially we're creating a bunch of header bloat (creating duplicate
> header fields with different names where that could be avoided) because
> there are some MTAs that did not follow the specifications before. That
> makes me unhappy, but what matters here is not the behavior of all MTAs,
> it's the behavior of MTAs implementing ARC (that include instance number
> tag/value). If there's an MTA in the middle that deletes DKIM-Signature,
> it's not implementing ARC and the chain is broken.
>

The DMARC WG is explicitly *not* scoped to make normative changes to any
other specifications so changing DKIM (for example) is not an available
option. Deleting or otherwise breaking one or more of the DKIM-Signatures
on a message has nothing to do with ARC per se. It's even possible that an
ARC-implementing ADMD could do such a thing.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2018 21:39:18 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>specifications before.

Not really.  Removing A-R headers and DKIM signatures that you know
you've broken is perfectly legit.

>While that was ~14 years ago and storage is 

The header bloat war was over years ago, and bloat won.  See the
headers below from a Hotmail message I just sent to myself.  And
remember that most messages have two copies of the contents, one as
text and one as overformatted HTML.

R's,
John

From: John Levine <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: foonly
Date: Thu, 12 Jul 2018 01:33:40 +0000
Accept-Language: en-US

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Jul 2018 20:33:16 -0700

On 7/11/18 6:23 PM, Kurt Andersen (b) wrote:
> On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton <[email-masked] 
>     specifications before. That makes me unhappy, but what matters
>     here is not the behavior of all MTAs, it's the behavior of MTAs
>     implementing ARC (that include instance number tag/value). If
>     there's an MTA in the middle that deletes DKIM-Signature, it's not
>     implementing ARC and the chain is broken.
>
>
> The DMARC WG is explicitly *not* scoped to make normative changes to 
> any other specifications so changing DKIM (for example) is not an 
> available option. Deleting or otherwise breaking one or more of the 
> DKIM-Signatures on a message has nothing to do with ARC per se. It's 
> even possible that an ARC-implementing ADMD could do such a thing.

I'm afraid I wasn't able to find that explicit statement in the charter. 
On the other hand, it says that one of the options the WG has is to 
propose "A form of DKIM signature that is better able to survive transit 
through intermediaries." So I don't see my suggestion as being out of scope.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jul 2018 23:45:12 -0700

On Wed, Jul 11, 2018 at 8:33 PM, Jim Fenton <[email-masked]> wrote:

> option.
> Why are we doing 7601bis then?  ;-)

> Deleting or otherwise breaking one or more of the DKIM-Signatures on a
> message has nothing to do with ARC per se. It's even possible that an
> On the other hand, it says that one of the options the WG has is to propose
> "A form of DKIM signature that is better able to survive transit through
> intermediaries." So I don't see my suggestion as being out of scope.
>

I agree that it's in scope for the charter, but we're pretty far down the
road of trying what we have before us to be going back to square one.

Given that we've settled on Experimental status, I propose this gets tabled
until that's published.  The experiment will establish what benefit ARC can
provide, which I think is the most important output of this work.  The
change being suggested here appears to be one of efficiency, not something
that will assist with evaluating that benefit.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2018 14:08:04 -0400

>that will assist with evaluating that benefit.

Having written and deployed a bunch of ARC code, I do not believe that
any sort of twiddle to try to combine one of the ARC headers with a
DKIM signature would be productive, and I have no interest in going
down that road.

As I said in a previous message, the bloat wars are over and bloat
won.  Nobody cares any more about avoiding a few hundred bytes of
message header.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Thu, 12 Jul 2018 15:26:57 -0700

> it's not implementing ARC and the chain is broken.

Note that ARC is designed so that non-participating relays which don't
break the latest AMS don't break the chain.

Not that I expect there are many relays which will delete a DKIM-Signature
and not otherwise break the AMS, though.

Also, the chain is added by the relays.  The DKIM-Signature means an
authority is verifying that a message was sent by them, and not having the
concept of instances, there is no way to know to show the difference
between relaying the message and sending the message.

Ie, google.com is certainly not going to DKIM-Sign a message from a third
party, that would imply authentication of the message as being google.com.
We have code in google groups to only sign outgoing messages if the
original message was authenticated, and even then, it means we sign things
we probably shouldn't.  We've even debated having a separate set of
outbound smtp servers to be used for that type of mail so they won't "gain"
SPF authentication on the relay.

AMS is different, it only indicates that the message transited the relay,
and only authenticates the ARC payload (the AAR header).   We actively use
the ARC chain now to prevent assigning sender authentication to relays.

Also also, bloat wise, it's the same.  DKIM-Signature is added by the
sender, AMS is added by the relays.  Even if ARC used DKIM-SIgnature, we'd
still be adding them on the relays, and they'd be similar in size.

Also, if we added the instance concept to DKIM, we are basically creating
DKIM v=2, which opens up the whole can of worms of whether or not there is
any benefit of versioning in some attempt at backward compatibility.  We'd
probably need to make it v=2 based on what is being authenticated.

During the discussion about whether or not AS was useful, I did point out
that if bloat was the issue, we could rejigger the AMS/AS to have a single
signature by having AMS just have a hash and AS then signing the AMS.  No
one thought the change was worthwhile.

As for the A-R header, I'd more say that A-R was designed for a very simple
purpose, to pass auth results from the inbound gateway to the end user
client or server.  That use case is more easily subsumed by the AAR than
the reverse, because of the limitations and implementations of the A-R
header as designed.  Trying to extend A-R runs into the same issues where
the chain will break on non-participating relays, and that hole I expect to
be a larger consideration.

Brandon

---

From: Jim Fenton <[email-masked]>
Date: Sun, 15 Jul 2018 14:27:37 -0400

> text and one as overformatted HTML.

I'm not particularly fond of the "everyone else is bloating their 
message headers, so we'll do more of that" argument. But I'll leave it 
at that.

However, the additional message header fields do require generation and 
verification. Generating and verifying AAR and AMS signatures requires 
additional computation (OK, Moore's Law so I shouldn't worry about that) 
and potentially additional public key retrieval from DNS. Verification 
of ARC Seals (and determining the oldest-pass value, if that is done) 
will probably require different public keys for each, which will 
probably create more DNS requests and may insert more latency as those 
responses are received.

I suggest that as part of WG Last Call that the DNS Directorate be 
consulted, largely to socialize this with them so they aren't surprised 
by the request load requirements.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Jul 2018 13:17:17 +0000

On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton <[email-masked]> wrote:

> consulted, largely to socialize this with them so they aren't surprised by
> the request load requirements.
>

Should the draft say more than what Section 9.2 already says?

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Mon, 16 Jul 2018 10:06:52 -0400

On 7/16/18 9:17 AM, Murray S. Kucherawy wrote:
> On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton <[email-masked] 
>     consulted, largely to socialize this with them so they aren't
>     surprised by the request load requirements.
>
>

9.2 describes the problem, but it's expressed in terms of a DoS attack 
on (primarily) validators. The DNS folk will be more concerned with the 
overall load on the infrastructure caused by ARC, not specifically on 
attack scenarios. So in consulting the DNS directorate, it would be good 
to mention the operational impact of 9.2.

I also wonder if it would be helpful to mitigate the operational impact 
by saying that AS SHOULD use the same selector as the associated AMS.

-Jim

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 16 Jul 2018 10:00:13 -0700

On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton <[email-masked]> wrote:

> 9.2 describes the problem, but it's expressed in terms of a DoS attack on
> (primarily) validators. The DNS folk will be more concerned with the
> attack scenarios. So in consulting the DNS directorate, it would be good to
> mention the operational impact of 9.2.
>
> I also wonder if it would be helpful to mitigate the operational impact by
> saying that AS SHOULD use the same selector as the associated AMS.
>

I would be opposed to adding the suggestion of this sort of restriction on
the basis of hypothetical load impacts.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Mon, 16 Jul 2018 11:37:50 -0700

> saying that AS SHOULD use the same selector as the associated AMS.

This has also been discussed several times on list, here's one such:
https://mailarchive.ietf.org/arch/msg/dmarc/XfS4UnLPrMbIhTvjYjmsYrcj_HA

Where this reach consensus (and it wasn't in the referenced thread, but I
couldn't find it after a brief search), was that no one had any technical
reason for a MUST or even a SHOULD in the spec, and that ultimately this is
matter of usage. So the usage guide should say that AMS and AS d=/s= should
match UNLESS you have a good reason to do otherwise, as receivers will most
likely treat it as suspicious if they don't.

We could see a clear example where the ARC Seal is signed by the
organizational entity, and the ARC Message Signature is signed by the
service. For instance, AS d=example.org, and AMS d=examplelists.org. This
translates to my ADMD takes overall responsibility for handling this
message, and this service within made a breaking change.

This seemed to be something that would become clear through the Experiment,
if everyone used the same key for both, then we could simplify the specl.
But if using separate keys ended up being valuable, and didn't create a
meaningful increase in DNS overhead, there was no reason to prohibit it
before seeing where the chips fell.

---

From: "John Levine" <[email-masked]>
Date: 16 Jul 2018 15:18:54 -0400

>the basis of hypothetical load impacts.

I agree with Kurt here.  I would be astonished if the extra load of
ARC lookups were even noticable other than in contrived scenarios.

In typical mail systems, every incoming message provokes a blizzard of
DNS lookups in DNSBLs for IP addresses and envelope domains, SPF, DKIM
keys, checking whether envelope and header address domains exist, and
DNSBL lookups up of every domain name in message bodies.  ARC is a
very slim straw on the back of this particular camel.

I do weird DKIM signatures where every signature has a different
selector, often with several signatures per message, and the DNS load
is still trivial.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Jul 2018 11:01:54 -0400

On 7/16/18 1:00 PM, Kurt Andersen (b) wrote:
> On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton <[email-masked] 
>>     On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>         I suggest that as part of WG Last Call that the DNS
>>         Directorate be consulted, largely to socialize this with them
>>         so they aren't surprised by the request load requirements.
>>
>>
>     9.2 describes the problem, but it's expressed in terms of a DoS
>     attack on (primarily) validators. The DNS folk will be more
>     concerned with the overall load on the infrastructure caused by
>     ARC, not specifically on attack scenarios. So in consulting the
>     DNS directorate, it would be good to mention the operational
>     impact of 9.2.
>
>     I also wonder if it would be helpful to mitigate the operational
>     impact by saying that AS SHOULD use the same selector as the
>     associated AMS.
>
>
> I would be opposed to adding the suggestion of this sort of 
> restriction on the basis of hypothetical load impacts.

It wasn't meant as a restriction. I was trying to decide on the right 
normative word to use here, and the IETF usage of SHOULD is probably too 
strong. I'd be happy with a MAY there; I don't think it hurts to point 
out that it's a good thing to do, from the standpoint of both DNS load 
and also extra lookups for the verifier.

-Jim

---

From: Seth Blank <[email-masked]>
Date: Tue, 17 Jul 2018 08:44:39 -0700

On Tue, Jul 17, 2018 at 8:01 AM, Jim Fenton <[email-masked]> wrote:

> strong. I'd be happy with a MAY there; I don't think it hurts to point out
> that it's a good thing to do, from the standpoint of both DNS load and also
> extra lookups for the verifier.
>

Jim, what if section 11.3.2 has a specific clause around one output of the
experiment being guidance on AS/AMS d=/s= binding language?