Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Dave Crocker <[e-mail]>]

On 8/11/2017 4:54 PM, Bron Gondwana wrote:
> On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:
> 
> I'm just picking out the key quote here:
> 
>> On 8/7/2017 4:22 PM, Seth Blank wrote:
>>
>>     When validating an ARC signed message, one verifies the latest AMS
>>     (which must validate), and *the entire chain* of ARC Seals, not only
>>     the latest. This guarantees you a list of all message signatories -
>>     the chain of custody we're talking about.
> 
> Yes, I follow this bit, but then...
> 
>>     When evaluating the chain for final receipt, there are two states to
>>     worry about as a matter of local policy: 1) you trust all the
>>     signatories on the chain 2) there is an untrusted signatory on the
>>     chain
> 
> Which is why it's a bad idea to sign if you're not modifying, because 
> then everybody has to trust you or their chain breaks, even though you 
> didn't do anything which required signing.

I don't have an opinion about whether this conclusion is correct, but 
I'm quite certain it a type of consideration that needs to be 
fundamental, to recommendations about usage.  Who should do what, and 
why?  What are the upsides of their doing or not?  Downsides?



>>     Without the ARC Seal this determination is not possible and there is
>>     no way to evaluate the ARC chain for delivery as a final receiver.
> 
> And this is the crux of our disagreement.  Seth thinks it's necessary to 
> do more than signing a statement that you believed the message was 
> authenticated when you got it, in a way that the next hop can verify 
> your signature over your own Authentication Results plus the content of 
> the message.  I disagree.
> 
> I'm proposing exactly the same stragety DKIM uses, just with series of 
> signed "chain of custody" statements rather than the DKIM signature 
> having to align with the sender domain.

by 'strategy DKIM uses' what do you mean exactly?  I'm guessing you mean 
having the signature cover more of the header and all of the body, but 
please confirm or clarify.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net