Subject: [dmarc-ietf] cv=invalid

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 14:32:25 -0700

I think this was discussed before, but perhaps it didn't reach a logical
conclusion:

If a verifier decides an ARC is invalid, it's supposed to set "cv=invalid",
when generating its own ARC-Seal.  This seems odd; we're cryptographically
signing a chain that is known to be broken, meaning the next handler might
not even be able to get as far as consuming the "cv=" value we're putting
there because the chain can't be validated in the first place.

Perhaps a better approach would be to use the regular A-R to indicate the
chain is bad, and stop.

Any other ideas?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 May 2017 14:47:18 -0700

On 5/31/2017 2:32 PM, Murray S. Kucherawy wrote:
> If a verifier decides an ARC is invalid, it's supposed to set 
> "cv=invalid", when generating its own ARC-Seal.  This seems odd; we're 
> cryptographically signing a chain that is known to be broken, meaning 
> the next handler might not even be able to get as far as consuming the 
> "cv=" value we're putting there because the chain can't be validated in 
> the first place.
> 
> Perhaps a better approach would be to use the regular A-R to indicate 
> the chain is bad, and stop.

+1, except I think not 'perhaps' but rather 'definitely'.

If it's broken, it's broken.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 1 Jun 2017 09:40:39 +0800

On Thu, Jun 1, 2017 at 5:32 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> cryptographically signing a chain that is known to be broken, meaning the
> next handler might not even be able to get as far as consuming the "cv="
> value we're putting there because the chain can't be validated in the first
> place.
>

Since looking at the ARC-Seal is the very first step in evaluating the
chain, I'm not sure why a handler would have a problem unless the ARC-Seal
is subsequently mangled beyond recognition (a situation which is covered
elsewhere). Signing the chain documents its state at the time of processing
and the AAR that is covered by the AS tells the next recipient where that
broken chain came from.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 21:09:38 -0700

> and the AAR that is covered by the AS tells the next recipient where that

So if on doing that very first step and evaluating the chain, I determine
that it's mangled and unparseable, I'm now supposed to add my own seal
including "cv=invalid" and somehow canonicalize the mangled thing that's
there already.  I don't think I understand how that's possible; the
canonicalized form that is hashed and encrypted to become the AS signature
has to include something deterministic.

-MSK