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

[Bron Gondwana <[e-mail]>]

On Tue, 15 Aug 2017, at 12:59, Seth Blank wrote:
> 
>> 
>> "might be useful to someone at some point" - that kind of wooliness
>> is a crock, sorry.  Once  crypto doesn't validate it has no meaning
>> if all the data is present elsewhere - and everything that an AMS
>> claims except for the crypto over the message is duplicated in the
>> next hop's AAR.>> 
>> If that's not the case, we should fix it so that it is.
>> 
>> "see what ends up being useful after this is in the wild for a bit"
>> makes sense for informational records.  It doesn't make sense for
>> cryptographic data.  Either the crypto is sound and it means
>> something, or it's actively misleading.  A no-longer-validating AMS
>> contains nothing that the next hop's AAR doesn't contain.> 
> So there have been two years of discussion about this on the list,
> and the consensus was that ARC will include trace information - like
> all non-originating AARs - because that information might be
> interesting or useful to some party at some point. Google has many
> instances where a non-originating AAR has the information that
> matters to them. But the tl;dr here is simply that the decision was
> made at its inception to include extra information that might be
> helpful later, and that the working group wasn't open to re-
> evaluating that decision because the body of ARC was built on it. If
> that's the design decision, then we need to be consistent in its
> application - which means not throwing out excess data, especially if
> someone says "that might be valuable to me.">  

Yes, trace information is good.  I absolutely agree that you need to
keep all the AARs.
The problem with AS is that it's not trace information in any meaningful
way over time.  The AS only validates while that key is still published,
so it's not "forever".
(mind you, nothing validates forever, the AMSes only validate while they
key is still in DNS too)
The fact that there was an AMS gets captured in the next AAR.

>>  
>>>> I just had a really good chat with Seth on Skype half an hour ago
>>>> about this.  He was unable to find a case where having a full
>>>> AS,AMS,AAR adds any provable value over just checking the most-
>>>> recent AMS and having AAR signed.  I do like your proposal of
>>>> signing ALL the existing AARs, because they're the thing of value.
>>>> Old AMS have no value, and old AS have no value either so long as
>>>> you have a cv=pass on the current AS.>>> 
>>> That's not quite what I said ;-)
>> 
>> 
>> OK, did I misunderstand?
>> 
>> You  couldn't quote a case where AS,AMS,AAR adds provable value over
>> an AMS that signs the most recent AAR.  If you can find that case, I
>> will eat all my words, because I've spent a lot of time thinking
>> through the cases.>> 
>> I agree with what Brandon seemed to be saying above - that it should
>> be all the AAR being signed, not just the top one.  Otherwise an
>> intermediate could strip or modify earlier AAR without breaking the
>> authentication, and that would be bad.  Each AAR contains real,
>> valuable, meaningful data.> 
> I said the AS forces anyone who modified the chain to sign. In the
> obvious "all trusted" and "clearly untrusted" signers cases, the AS
> doesn't seem to add much value. But if a bad actor finds a way to send
> a chain through a good intermediary, then not having an AS would allow
> this message to be delivered. This is an edge case, and maybe doesn't
> matter - but the AS certainly protects against it.
Can you please expand on this point and show how the AS is protecting
against a bad actor sending a chain through a good intermediary.  I
really don't see it.  An example of AS protecting against a bad actor
here would totally blow my argument out of the water.
> 
> The spec already covers all AARs by the AS.
>  
>> 
>> 
>> As far as I see, we're quibbling over how much cryptographic
>> infrastructure is needed to maintain the integrity of the chain of
>> AAR headers.>> 
>> 
>>> If you throw old AMSs out, you cannot validate current ASs or walk
>>> the chain back.>> 
>> 
>> So what.  AS is bunk.
>> 
>> A current AMS over all AAR gives the same auditability, since AAR is
>> the only thing that has meaning.  AMS only has meaning while it still
>> validates, and AS only has meaning because it ties AMS and AAR
>> together.  Those meanings don't add value.  None of them mean jack
>> once you've been through an untrusted site, all previous headers are
>> suspect regardless of whether they have crypto that still validates,
>> unless that crypto covers facts about the message which we actually
>> care about.> 
> I thought our discussion ended with the AS adding an extra layer that
> was benign at worst, and protected against future unknown attacks at
> best. And your concern was the overhead of evaluating the AS on DNS,
> especially for long chains. I thought where we ended was your
> suggestion that the spec only requiring validation of the latest AS
> and AMS, and implementations MAY validate all AS's if they wish.> 
> If this is the case, then we can't throw out any AMS because none of
> the ASs would validate any longer.>  
>> 
>>> 
>>> I'll suggest language for stamping "first AMS failure", but we
>>> shouldn't strip old AMS/AS headers.>> 
>> 
>> This is where we disagree.  We shouldn't create AS headers in the
>> first place.> 
> This is 180 degrees from where we left off on the call. 

That is true.   We discussed an alternative world in which we keep the
AS but reduce the validation requirement.  That's my fallback position
if I can't convince people that AS is pointless.  It's not my preferred
position, which is where I went in response to Brandon's post.
>> We should have AMS sign all the AAR and that's it.  No AS, no need to
>> retain broken AMS.>> 
>> It gets you all the same machine readable chain of custody as
>> AS+AMS+AAR  in the unbroken case, and it breaks at the same place
>> with the same detectability in the fraudulent-actor case.> 
> I'll let someone who's more familiar with where ARC started from - my
> understanding was that ARC stemmed from something similar to AMS+AAR
> being insufficient, but I don't have enough context here to provide
> meaningful insight.
I would love to see that.

If you can show me a case where AS protects against a bad actor, and
where having the latest AMS signing all AAR doesn't provide equivalent
protection, I will eat a whole lot of crow and crawl back in my corner,
because I don't see it.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]