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

[Bron Gondwana <[e-mail]>]

On Sat, 19 Aug 2017, at 04:51, Brandon Long wrote:
> 
> 
> 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 think I agree with you here - that keeping AS but breaking old ones by
removing AMS is the opposite of useful.
> 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).
Before I joined - maybe I should read back further!  This makes sense to
me, certainly two separate signatures (AS and AMS) is wasteful and
meaningless.  Which one the signature actually sits on doesn't matter at
all from a topological viewpoint, only what the signature covers
matters.  A signature on the AS which signed an AMS-like header that was
just a hash over the content would be fine.  Having the AMS-like header
calculated in such a way that if a site didn't modify the content of the
message, it also didn't modify the AMS hash would be super fine.
As a matter of fact, I really like this.  An AMS that doesn't have a
signature, but covers the content in a repeatably defined way, and
possibly even a way that can adapt to minor changes (changing from
address, stripping or adding MIME parts, etc) such that modifiers could
modify in a way that allowed provenance of the bulk of the message
payload to be tracked through them.  Being able to assert "I only
modified the message in these ways" in a way that could be verified
would be fantastic as an intermediate - and it would stop me doing what
I did in my last email and completely faking a valid ARC chain on a fake
message from Brandon.  I could only modify the message in limited ways
without tipping my hand.
> Another option would be to change our expectations, that is to say
> that signing by non-modifying hops is optional.
For sure.  Either changing ARC so that non-modifying hops sign but don't
change the AMS-like hash (so it's clear they didn't modify), or saying
that signing by non-modifying hops is at least a SHOULD NOT.
My goal with everything that I'm suggesting is to increase the ability
to determine provenance of the message payload.  The mail flow itself is
always going to be easily faked.[1]
DKIM doesn't assert anything about mail flow - you can receive a DKIM-
signed message and regardless of the route it's traveled, you know that
the payload was unmodified since it left the jurisdiction which had
access to the private key for its signing domain.
ARC as currently defined is weak on maintaining provenance on the
payload.  But provenance on the payload is what really matters, because
falsifying the payload is where attacks against email integrity get
their value.
Bron.

[1] footnote on this - I have alluded to crypto header rewriting such
    that you can't rewind.  I'll write a separate email on that topic.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]