Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

From: Brandon Long <[email-masked]>
Date: Fri, 3 Aug 2018 10:24:21 -0700

I know I lost the argument on cv (I think cv is entirely superfluous and
there's no point adding/signing a cv=fail header), but it seems the
argument for that is more data.  That said, this "either or" signing set
thing on cv=fail seems pretty cumbersome.

Brandon

On Mon, Jul 30, 2018 at 5:42 PM John R Levine <[email-masked]> wrote:

> > The working group considered cv=invalid last year, but there was strong
> > consensus was against it. The guidance for Sealing cv=invalid Chains
> > somehow made it into this draft applied to all cv=fail Chains. All Chains
> > should be Sealed in the same fashion (your AS covers the ARC Set you've
> > added and all previous ARC Sets), unless the Chain is invalid in which
> case
> > you only Seal your own ARC Set.
>
> Ah.  Perhaps reword 5.1.1 like this:
>
> The signature of an AS header field signs a specific canonicalized
> form of the ARC Set header values, when all of the previous ARC sets
> are valid. In that case, the ARC set header values are supplied to the
> hash function in increasing instance order, starting at 1, and include
> the ARC Set being added at the time of Sealing the message.  If any of
> the existing sets are invalid, the AS header field only signs its own
> ARC Set.
>
> Within an ARC Set, header fields are supplied to the hash function in the
> following order:
>
> 1. ARC-Authentication-Results
> 2. ARC-Message-Signature
> 3. ARC-Seal
>
> The ARC-Seal is generated in a manner similar to when DKIM-Signatures
> are added to messages ([RFC6376], section 3.7).
>
>
> In 5.1.2:
>
> In the case of a failed Authenticated Received Chain, the header
> fields included in the signature scope of the AS header field b= value
> MUST only include the ARC Set headers in the newly created set, as if
> this newest ARC Set was the only set present.
>
>
> In 5.2, oldest pass is confusing, since it doesn't tell you whether
> the validation succeeds or not.  I would take out steps 5-7 and add
> something to the INFORMATIONAL at the end like "A validator can check
> the AMS headers to estimate when in a chain of forwards the message
> was modified."
>
>
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "John R Levine" <[email-masked]>
Date: 3 Aug 2018 13:54:01 -0400

> thing on cv=fail seems pretty cumbersome.

You guys have looked at as many ARC signatures as anyone.  Once the chain 
has a cv=fail do you learn anything useful from further seals?

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Fri, 3 Aug 2018 11:00:18 -0700

Currently, we don't do anything with failed chains short of keeping stats.
Everything we've used the chain for so far has been from passing chains.

That said, we still only trust our own chain elements, we haven't seen wide
enough adoption to spend much effort on interpreting chains which
involve multiple parties.

Brandon

---

From: Seth Blank <[email-masked]>
Date: Fri, 3 Aug 2018 16:13:47 -0700

On Fri, Aug 3, 2018 at 11:00 AM, Brandon Long <
blong=[email-masked]> wrote:

> Currently, we don't do anything with failed chains short of keeping
> stats.  Everything we've used the chain for so far has been from passing
> chains.
>

Especially as an Experiment, I think it's important to sign even failing
chains, especially for the reasons I've already enumerated. Otherwise, the
above scenario - only data from passing chains is usable - is the only
possible scenario. This seems myopic, especially when we don't yet know
what the real world landscape will look like.

---

From: Brandon Long <[email-masked]>
Date: Mon, 6 Aug 2018 17:46:11 -0700

> what the real world landscape will look like.

Do we actually have consensus on what to do, though?

The current proposal seems pretty bad, sign one or all depending on vague
things that might be different per impl.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 7 Aug 2018 08:37:57 -0700

> things that might be different per impl.

It does not seem to me like we have consensus. Can we pick one option for
this experimental phase and re-evaluate afterward? For the sake of
non-ambiguity, I'd suggest the "sign one" approach. During the experiment
we can see how often it has to be invoked and request people to examine
those cases for further evaluation.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 11 Aug 2018 21:20:07 +0000

On Tue, Aug 7, 2018 at 3:37 PM, Kurt Andersen (b) <[email-masked]> wrote:

> On Mon, Aug 6, 2018 at 5:46 PM, Brandon Long <blong=40google.com@dmarc.
> ietf.org> wrote:
>
>>

"Sign one" (I think you mean "seal one") remains ambiguous to me, because
as Seth said, once I see "cv=fail", I don't care about anything else.  Now
I have a seal nobody cares about, which means the sealer shouldn't be
bothered with generating it, irrespective of what gets fed to the hash.

Can we clear that part up?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Aug 2018 14:31:52 -0700

On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote:
> Sign one" (I think you mean "seal one") remains ambiguous to me, because 
> as Seth said, once I see "cv=fail", I don't care about anything else.  
> Now I have a seal nobody cares about, which means the sealer shouldn't 
> be bothered with generating it, irrespective of what gets fed to the hash.
> 

+1*10**inf.

There has been a persistent desire to find a way to continue to process 
an ARC sequence that is broken, as if that will somehow make it unbroken 
or, at least, /less/ broken.

It won't.

As soon as a broken ARC chain is detected, ARC is -- or at least should 
be -- finished.  ARC-aware not should stop processing ARC for that 
message.  Completely stop.

If there is a clear and compelling counter-argument of clear benefit 
that can be achieved, will be achieved, and is desired by receivers, 
what is it?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Tue, 14 Aug 2018 20:58:55 -0700

On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker <[email-masked]> wrote:

> If there is a clear and compelling counter-argument of clear benefit that
> can be achieved, will be achieved, and is desired by receivers, what is it?

There are THREE consumers of ARC data (forgive me for the names, they're
less specific than I'd like):

1) The ARC Validator. When the Validator sees a cv=fail, processing stops,
the chain is dead, and shall never be less dead. What is Sealed is
irrelevant.

2) The Receiver. An initial design decision inherent in the protocol is
that excess trace information will be collected, as it's unclear what will
actually be useful to receivers. 11.3.3 calls this out in detail. Without
Sealing the entire chain when attaching a cv=fail verdict, none of the
trace information is authenticatable to a receiver (see earlier message in
this thread as to why), which is the exact opposite of the design decision
the entire protocol is built on. To guarantee this trace information can be
authenticated, the Seal that contains cv=fail must include the entire chain
in its scope. This is where this thread started.

3) The receiver of reports that provide ARC data. For a domain owner to get
a report with ARC information in it, there needs to be some level of trust
in the information reported back. When a Chain passes, all the
intermediaries' header field signatures can be authenticated, and the
mailflow can be cleanly reported back. When a Chain fails, that is
important information to a domain owner (where is my mailflow failing me,
how can I figure this out so I can fix it?). Again, without Sealing over
the entire Chain when a failure is detected, this information is
unauthenticatable (and worse, totally forgeable now without even needing a
valid Chain to replay), and nothing of substance can be reported back.
Sealing the Chain when a cv=fail is determined blocks forgery as a vector
to report bogus information, and allows authenticatable information to be
reported back.

So to recap: Yes, when you hit cv=fail the chain is dead and shall never be
less dead. But to preserve trace information as was the initial design
decision, and make sure report data is meaningful and cannot be forged,
when a cv=fail verdict is attached the Seal must cover the entire chain in
its scope.

And to be even clearer: what is Sealed when cv=fail is reached (itself, the
entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. But it
does effect preserving trace information and preventing forged data from
being reportable.

This is my very strong INDIVIDUAL opinion. But I'm fine if the group sees
differently, as this could be investigated as part of the experiment (i.e.
do any of the above points matter in the real world? I say they do, hence
the strong opinion.). As an editor, I'll make sure whatever the consensus
of the group is is reflected in the document.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 14 Aug 2018 22:28:36 -0700

On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker <[email-masked]> wrote:

> There has been a persistent desire to find a way to continue to process an
> ARC sequence that is broken, as if that will somehow make it unbroken or,
> at least, /less/ broken.
>
> It won't.
>
> As soon as a broken ARC chain is detected, ARC is -- or at least should be
> -- finished.  ARC-aware not should stop processing ARC for that message.
> Completely stop.
>

Looking at how ARC chains can fail through the lens of the the validation
protocol (
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-15#section-5.2):

   1.  steps 1-3 are all pre-crypto structural checks.  Most of the
   discussion and concern has been in regard to these sorts of structural
   failures being introduced by broken implementations or mis-behaving MTAs in
   the intermediary stages. Up through version 4, we designated such
   structural failures with a "cv=invalid" flag and A-R(arc)=unknown so that
   no one would waste further time or resources looking at them;
   2. step 4 validates the most recent AMS. If it is broken, then we know
   nothing about the content being conveyed so "cv=fail" + A-R(arc)=fail makes
   sense or we could get more specific with A-R(arc-ams)=fail (not currently a
   defined designation);
   3. step 8 (should be 6 if the sub-items had been properly indented)
   validates the sequence of AS header values. If those do not validate, then
   the integrity of the chain itself is unfounded. We currently also designate
   this with "cv=fail" and A-R(arc)=fail but we could distinguish it from
   failure mode 2 with A-R(arc-as)=fail instead.

The only reason to affix a seal with "cv=fail" on the end of an ARC chain
is to spare all subsequent handlers from having to venture past step 2 in
the validation process. Without that, every intermediary and the final
receiver (at least those which validate ARC) will have to repeat the entire
sequence of validation up to whatever point in the process a failure is
determined. If we want (for some reason that I still don't understand) to
have a broken chain "preserved" for hypothetical forensics, we can't do it
under conditions of malformation because we have no deterministic list of
ARC header fields *to* seal. We could do something defined for failure
cases 2 and 3 and some structural violations, but not for all structural
violations. That's why I remain convinced that what is currently called for
in the spec is the only workable approach.

--Kurt

---

From: Dotzero <[email-masked]>
Date: Wed, 15 Aug 2018 05:58:18 -0400

On Wed, Aug 15, 2018 at 1:28 AM, Kurt Andersen (b) <[email-masked]> wrote:

> protocol (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-
> 15#section-5.2):
>
+1. I understand the desire for more but I agree with Kurt.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Aug 2018 06:33:46 -0700

On 8/14/2018 10:28 PM, Kurt Andersen (b) wrote:
> The only reason to affix a seal with "cv=fail" on the end of an ARC 
> chain is to spare all subsequent handlers from having to venture past 
> step 2 in the validation process. Without that, every intermediary and 
> the final receiver (at least those which validate ARC) will have to 
> repeat the entire sequence of validation up to whatever point in the 
> process a failure is determined. 

So the extra mechanism is intended an efficiency hack.

1. The processing being saved is merely normal processing that they'd be 
expected to do for a valid message.

2. I hope we are assuming that failure is not a typical condition

3. In order to save some occasional processing in some cases, we are 
adding mechanism to all implementations everywhere.

This doesn't sound like compelling benefit, which is why I suggest 
removing it.  Absent compelling benefit, simpler specifications is to be 
preferred, IMO.

d/

---

From: Seth Blank <[email-masked]>
Date: Wed, 15 Aug 2018 07:29:40 -0700

> removing it.  Absent compelling benefit, simpler specifications is to be

Absolutely agreed on simplifying the spec, but the above conversation
misses the points in the email I sent an hour or two earlier.

In particular, there was a design decision made at the genesis of ARC to
store excess trace information that receivers could use to further analyze
the Chains on the receipt. This is well documented in 11.3.3, as part of
the experiment is looking into what trace information is actually valuable.

As I've mentioned previously several times in this thread, without the Seal
that affixes cv=fail to the message including all the ARC header fields in
its scope, this trace information is no longer authenticatable and
therefore cannot be trusted. This is a violation of the explicit design
decision this protocol was built up from.

But to also reiterate: what is Sealed when cv=fail is attested to (itself,
the entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. What
it does effect are preserving trace information and preventing forged data
from being reportable. This seems deeply valuable to me.

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2018 14:30:21 -0400

>So the extra mechanism is intended an efficiency hack.

No, it also documents the fact that the chain was broken when it
arrived at the cv=fail signer.  Without it, a subsequent hop can't
tell.  It probably won't make much difference to spam filters, but
it could be useful if you're trying to find and fix forwarders
that make gratuitous changes.

I think there's a modest benefit to signing with cv=fail, and since
you can't count on having a chain (even an invalid one) signing as
if it were cv=none seems reasonable.

R's,
John

PS: Once there is a cv=fail seal, there doesn't seem to be any point
to adding any more seals in later hops.  It's dead, Jim.

---

From: Seth Blank <[email-masked]>
Date: Wed, 15 Aug 2018 11:41:18 -0700

> that make gratuitous changes.

Exactly.

> if it were cv=none seems reasonable.

It's this, as well as what I outlined in my previous message.

> to adding any more seals in later hops.  It's dead, Jim.

Absolutely, and the spec very clearly said this prior to the -15 reorg, but
it appears that has disappeared. Fixed.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Aug 2018 11:48:39 -0700

> if it were cv=none seems reasonable.

Modest, indeed.  Also unknown.

This is building in a permanent behavior, for a use that is, at best, 
vague conjecture.

d/

---

From: "John R Levine" <[email-masked]>
Date: 15 Aug 2018 14:53:07 -0400

On Wed, 15 Aug 2018, Dave Crocker wrote:
> This is building in a permanent behavior, for a use that is, at best, vague conjecture.

Well, sure, but we could say that about all of ARC.  As far as I know 
nobody has any rules yet for evaluating ARC chains beyond "if it was 
originally from us and the chain is good, it's probably OK."

The cost of adding the cv=fail signature is pretty low, and I don't see 
any way that it would make things worse.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Aug 2018 12:01:45 -0700

On 8/15/2018 11:53 AM, John R Levine wrote:
> Well, sure, but we could say that about all of ARC.

No we can't.

This is a very different kind and degree of vague (and without 
precedent, I believe (unless someone can point to operational experience 
on the net that is similar?)

d/

ps. Hmmm. Unfortunately, this exchange does highlight that the 
considerable complexity of ARC is not really built upon any clear model 
of how all its provided information is expected to be used...

---

From: "John R Levine" <[email-masked]>
Date: 15 Aug 2018 15:54:21 -0400

On Wed, 15 Aug 2018, Dave Crocker wrote:
> This is a very different kind and degree of vague (and without precedent, I 
> believe (unless someone can point to operational experience on the net that 
> is similar?)

I believe there are lots of trace fields that don't have a concrete use. 
I am not familiar with any standardized use of the values in the ID field 
in Received headers, although they're often handy in practice to track 
down the details of what happened to a message.

Can you explain in words the damage that cv=fail signatures will cause, 
and a rough idea of the cost to ARC signers and verifiers?  To me the 
answers are none, and trivial.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Aug 2018 13:13:43 -0700

> answers are none, and trivial.

You have the obligations reversed.  When adding things -- which adds 
overhead and makes the system more complicated and increase the 
likelihood of bugs -- the affirmative obligation is on folk advocating 
the addition.

As for the fact that there are other mechanisms of limited or unknown 
benefit that we've had, possibly for a long time, everything about ARC 
is significantly more complicated, including this failure add-on.

And the add-on is of especially unclear benefit.  It has intuitive 
appeal, which seems to get in the way of being able to clearly address 
actual need and benefit.

At any rate, I've expressed my concerns more than amply and don't feel 
the need of arguing my position further.

d/

---

From: "Brotman, Alexander" <[email-masked]>
Date: Fri, 17 Aug 2018 19:43:18 +0000

I'd say that I agree with John (and Seth) on this one.  I'm not sure if a consensus was reached, though it doesn't appear so.  I think the idea that being able to have trust in the broken chain information potentially sent back to us as a report has value.  It's hard to be sure that the value will override the cost of the signature, but as John suggested below, I can't imagine the cost to be very high.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of John R Levine
Sent: Wednesday, August 15, 2018 3:54 PM
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

On Wed, 15 Aug 2018, Dave Crocker wrote:
> precedent, I believe (unless someone can point to operational 
> experience on the net that is similar?)

I believe there are lots of trace fields that don't have a concrete use. 
I am not familiar with any standardized use of the values in the ID field in Received headers, although they're often handy in practice to track down the details of what happened to a message.

Can you explain in words the damage that cv=fail signatures will cause, and a rough idea of the cost to ARC signers and verifiers?  To me the answers are none, and trivial.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 17 Aug 2018 14:29:59 -0700

I'm still at a bit of a loss as to how one can effectively do a "greedy"
seal over a broken chain in a deterministic fashion. I'm also not sure why
one would report much of anything (back to the hypothetical sending domain)
from a broken chain, given that it has no validity.

--Kurt

On Fri, Aug 17, 2018 at 12:43 PM, Brotman, Alexander <
[email-masked]> wrote:

> I'd say that I agree with John (and Seth) on this one.  I'm not sure if a
> consensus was reached, though it doesn't appear so.  I think the idea that
> being able to have trust in the broken chain information potentially sent
> back to us as a report has value.  It's hard to be sure that the value will
> override the cost of the signature, but as John suggested below, I can't
> imagine the cost to be very high.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse
> Comcast
>
>
> in Received headers, although they're often handy in practice to track down
> the details of what happened to a message.
>

---

From: "John R Levine" <[email-masked]>
Date: 17 Aug 2018 18:13:33 -0400

> seal over a broken chain in a deterministic fashion.

I've been discussing this with Seth.  Particularly once we start doing 
parallel chains for different algorithms, different implementations will 
disagree about what's a broken chain, so I'd just as soon not try.

If the previous seal was good, add cv=fail only signing your own seal.  If 
the previous seal was cv=fail, don't sign.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Aug 2018 03:28:40 -0700

(back from vacation and catching up)

> the chain is dead, and shall never be less dead. What is Sealed is

Right.

> in its scope. This is where this thread started.

I see two possible workflows here:

(1) Verifier (to use the DKIM term) detects "cv=fail" and stops, because
there's nothing more to do.  But the Receiver now has no ARC information
except a raw "cv=fail" to relay via A-R or whatever.  But this, as you
point out, flies in the face of the notion of giving receivers details
about the message.  The Receiver now has to implement ARC to get whatever
details might be prudent from the message.

(2) Verifier sees "cv=fail" but will still attempt to verify it and maybe
extract other salient details to add to an A-R.

When you say "you see cv=fail and stop", I think of the first thing, which
is alarming layer mush, and is also ambiguous in that if the Verifier stops
dead at seeing "cv=fail", it doesn't matter at all what content got sealed.

So if you mean the second thing, part of my issue goes away.

> to report bogus information, and allows authenticatable information to be

I think we're talking about distinct failure modes.  I totally agree with
you in the case where the chain has failed because content was altered.
But doesn't your assertion here presuppose an at least syntactically intact
chain?  If the chain is damaged to the point where it cannot be
deterministically interpreted, the sealer adding the "cv=fail" might add a
seal that a downstream verifier cannot correctly interpret.

I understand what you're after but I also understand the intent behind
5.1.2, which is to produce something unambiguous.  My problem with 5.1.2 as
it stands is that a verifier now has to try verifying the "cv=fail" two
ways (one with everything, one with just the last instance), and at least
one of them has to work.  We've cornered ourselves here by rejecting
"cv=invalid".

>
> And to be even clearer: what is Sealed when cv=fail is reached (itself,
> the entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. But
> it does effect preserving trace information and preventing forged data from
> being reportable.
>

I disagree, as stated above; a mangled chain cannot be sealed in a way
guaranteed to interoperate.

> of the group is is reflected in the document.

I've no objection to collecting superfluous trace information to support
the experiment.  What I'm concerned about is the introduction of weird
protocol artifacts or ambiguities that could get baked in and hard to
remove later.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Aug 2018 10:02:48 -0400

Hi,

I agree with your comments.

My input.

Keep in mind, that ignorant (non-supportive) ARC nodes will continue 
to process all DKIM-signature(s) found, such as what I see with your 
message:

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=none author.d=gmail.com signer.d=ietf.org;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=none author.d=gmail.com signer.d=ietf.org;
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com 
header.s=20161025 header.i=gmail.com;
  adsp=none author.d=gmail.com signer.d=gmail.com;

That should be the first consideration and understanding in the 
pre-ARC DKIM world, i.e. how things are done now.

The order of the DKIM-signatures is generaly important here since the 
typical scenario (with a list) is:

  1) Good 1st original Author Domain signature is submitted,
  2) 1st signature invalidated at middle ware (LIST),
  3) Good 2nd Signature (resign) for LIST distribution
  4) MDA see failed original AUTHOR ADSP/DMARC Policy.

Overall, the MDA has no explicit 3rd party trust/policy knowledge of 
LIST or signatures beyond the 1st Author Domain (now broken) 
signature.  That's the basic issue and 12+ years old DKIM Policy model 
protocol dilemma.

I suppose there could be more middle ware, nodes, etc during the 
transport, but the First and Final processing nodes should be the 
essential protocol consideration.  If there is an cv=fail at #2, does 
that mean the resigning at #3 is invalidated as well?  We never really 
cared what happens in between during the transport, but with ARC it 
appears to be a major consideration to better understand transport 
paths.  How ARC will turn all this around, it remains to be be seen. I 
wish to understand this complex protocol first before justifying the 
massive overhead and experimentation cost being asked of SMTP/Email 
developers.

Thanks

Hector Santos, CTO
Santronics Software, Inc.

On 8/20/2018 6:28 AM, Murray S. Kucherawy wrote:
> On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     There are THREE consumers of ARC data (forgive me for the names,
>     they're less specific than I'd like):
>
>     1) The ARC Validator. When the Validator sees a cv=fail,
>     processing stops, the chain is dead, and shall never be less dead.
>     What is Sealed is irrelevant.
>
>
> Right.
>
>     2) The Receiver. An initial design decision inherent in the
>     protocol is that excess trace information will be collected, as
>     it's unclear what will actually be useful to receivers. 11.3.3
>     calls this out in detail. Without Sealing the entire chain when
>     attaching a cv=fail verdict, none of the trace information is
>     authenticatable to a receiver (see earlier message in this thread
>     as to why), which is the exact opposite of the design decision the
>     entire protocol is built on. To guarantee this trace information
>     can be authenticated, the Seal that contains cv=fail must include
>     the entire chain in its scope. This is where this thread started.
>
>
> (1) Verifier (to use the DKIM term) detects "cv=fail" and stops,
> because there's nothing more to do.  But the Receiver now has no ARC
> information except a raw "cv=fail" to relay via A-R or whatever.  But
> this, as you point out, flies in the face of the notion of giving
> receivers details about the message.  The Receiver now has to
> implement ARC to get whatever details might be prudent from the message.
>
> (2) Verifier sees "cv=fail" but will still attempt to verify it and
> maybe extract other salient details to add to an A-R.
>
> When you say "you see cv=fail and stop", I think of the first thing,
> which is alarming layer mush, and is also ambiguous in that if the
> Verifier stops dead at seeing "cv=fail", it doesn't matter at all what
> content got sealed.
>
>     3) The receiver of reports that provide ARC data. For a domain
>     owner to get a report with ARC information in it, there needs to
>     be some level of trust in the information reported back. When a
>     Chain passes, all the intermediaries' header field signatures can
>     be authenticated, and the mailflow can be cleanly reported back.
>     When a Chain fails, that is important information to a domain
>     owner (where is my mailflow failing me, how can I figure this out
>     so I can fix it?). Again, without Sealing over the entire Chain
>     when a failure is detected, this information is unauthenticatable
>     (and worse, totally forgeable now without even needing a valid
>     Chain to replay), and nothing of substance can be reported back.
>     Sealing the Chain when a cv=fail is determined blocks forgery as a
>     vector to report bogus information, and allows authenticatable
>     information to be reported back.
>
>
> I think we're talking about distinct failure modes.  I totally agree
> with you in the case where the chain has failed because content was
> altered.  But doesn't your assertion here presuppose an at least
> syntactically intact chain?  If the chain is damaged to the point
> where it cannot be deterministically interpreted, the sealer adding
> the "cv=fail" might add a seal that a downstream verifier cannot
> correctly interpret.
>
> 5.1.2, which is to produce something unambiguous.  My problem with
> 5.1.2 as it stands is that a verifier now has to try verifying the
> "cv=fail" two ways (one with everything, one with just the last
> instance), and at least one of them has to work.  We've cornered
> ourselves here by rejecting "cv=invalid".
>
>     And to be even clearer: what is Sealed when cv=fail is reached
>     (itself, the entire chain, or nothing at all) DOES NOT AFFECT
>     INTEROPERABILITY. But it does effect preserving trace information
>     and preventing forged data from being reportable.
>
>
>     This is my very strong INDIVIDUAL opinion. But I'm fine if the
>     group sees differently, as this could be investigated as part of
>     the experiment (i.e. do any of the above points matter in the real
>     world? I say they do, hence the strong opinion.). As an editor,
>     I'll make sure whatever the consensus of the group is is reflected
>     in the document.
>
>
> I've no objection to collecting superfluous trace information to
> support the experiment.  What I'm concerned about is the introduction
> of weird protocol artifacts or ambiguities that could get baked in and
> hard to remove later.
>
> -MSK
>