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

[Brandon Long <[e-mail]>]

On Fri, Aug 18, 2017 at 10:00 AM, Seth Blank <[e-mail]> wrote:

> On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen <[e-mail]> wrote:
>
>> So I was able to retrace our design steps which led to the 3-piece model
>> (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header
>> sequence was to provide the verifiable chain of custody trace (though, of
>> course, only from participating intermediaries). Some of the recent tweaks
>> to the spec to deal with malformed sets of ARC header fields have weakened
>> that original idea.
>>
>> In keeping with Bron's general idea to simplify, I'd suggest that having
>> an AAR + [optional AMS] + AS would be a close approach for handling steps
>> which do not break the ingress signature. Skipping the AMS would be a sign
>> to downstream intermediaries that the prior DKIM or AMS was still valid
>> upon egress. (certain details would have to be worked out)
>>
>> Does that help the conversation?
>>
>
> No, I think this is a huge step in the wrong direction.
>
> Right now, we've got deployed code that we know works and improves the
> landscape. Everything else is - rightly or wrongly - conjecture.
>
> Let's keep the tech stable and move to experimentation.
>
> If anything, this is an excellent question for receivers - when evaluating
> AMS/AS, were there any situations where you required both signatures to
> truly validate a chain and make a delivery decision, or with the added ARC
> payload is now just having one sufficient?
>

I'm leary that removing the AMS on certain hops is the right choice, here.
Without the AMS, the extra AAR/AS is not tied to this message directly, so
I'm unsure how to handle any assertions made in the AAR.  This also feels
like the opposite of what Bron is asking for.

I also proposed a month or so back some simplifying changes which were
largely met with radio silence, that would have partially mitigated some of
Bron's operational concerns, notably to either require the s/d be the same
on AS/AMS or to eliminate the signature and s/d on AMS completely,
switching the AMS to a hash that would then be covered by the AS.  That
doesn't reduce the number of crypto ops as much as his AMS only based
proposal (which presumably would halt at the first broken AMS).

Another option would be to change our expectations, that is to say that
signing by non-modifying hops is optional.

Brandon