Sorry, posted from the wrong address, trying again.
On Aug 9, 2017 8:41 PM, "Brandon Long" <bl...@google.com> wrote:
> We discussed this exact situation extensively during several M3AAWG
> meetings, so I don't think we're missing something... but maybe.
> With AS I can trust the chain and use the older hops AAR. And whether to
> use a given hops AAR is based on my trust level for that hop.
> As long as the AMS passes, you can ignore hops you don't trust and keep
> Once you reach a hop where the AMS doesn't verify, you can only walk back
> to hops you trust, and untrusted hop ends your walk back.
> So, you can copy and entire chain on to whatever message you want, but
> that only works if I trust you. If you do this a lot, we won't trust you
> any more.
> This doesn't mean that some messages can't abuse the trust relationship
> and make it through, and we specifically say that standard
> spam/phishing/abuse analysis should still be done.
> With your proposed AAR signed by the AMS, I can only trust your AAR, and
> whatever you choose to put in it, not anyone in front of you.
> With XOAR, we have experience with that type of single hop working system,
> and it's not complete enough, we see too many complicated routing policies
> which go through many hops, and the last hop data isn't always enough. We
> work around it with from header rewrites and signing as the intermediary
> domain, but then we need to make decisions on when to do so since dkim
> means something different than ams does.
> Also, you wouldn't expect to see arc signed messages from this list until
> it starts doing them itself, unless people are posting to it though another
> intermediary or you receive it through a separate intermediary.
> On Aug 9, 2017 6:26 PM, "Bron Gondwana" <br...@fastmailteam.com> wrote:
>> On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote:
>> I think the "Once AMS doesn't validate anymore ..." argument is an
>> suggestion that it's fragile, not that it's pointless. I have concerns
>> myself about the robustness of this design, but I think that's best
>> addressed through deployment and experimentation.
>> It's not fragility, the older AMS is supposed to not validate any more,
>> because it's a signature over a bunch of headers and the body - any change
>> in those will break it. That's fine so long as the chain of custody exists.
>> My problem is that ARC-Seal only actually shows the chain of custody back
>> to the first bad actor. That's also fine, because any bad actor means the
>> whole message is tainted and should be discarded.
>> The thing is - ARC-Seal and verifying every Seal only gives more
>> integrity than checking the previous AMS and signing your own AAR unless
>> this is true:
>> * There exists a site which correctly checks ARC-Seal and adds new
>> ARC-Seals, but does not generate an accurate AAR.
>> I do feel like nobody understands what the hell I'm trying to say here
>> based on the responses I've seen so far, so maybe I do actually need to
>> find an existing ARC-Sealed email and forge a change to it. Seth asked to
>> have a phone chat about this, and I'm happy to have a phone chat with
>> anybody if it will help explain my point.
>> I'm not saying that the underlying concept of ARC are wrong - the idea of
>> chain of custody is sound.
>> The problem is that ARC-Seal makes claims it just doesn't deliver on -
>> it's not adding value, and it is adding cost and fragility (the need to
>> successfully do DNS fetches for every seal in the chain at every point,
>> plus the cost of checking that crypto) - and yet any one site can still
>> falsify all the earlier items in the chain.
>> Sadly I only have a few message in my entire mailbox that have ARC-Seals
>> on them. They're from a Mozilla Thunderbird list of all things, and they
>> have some Google ARC headers on them. I'd prefer to impersonate someone
>> from this list if I'm going to make a proof of concept to show what I mean,
>> but nobody appears to be sending messages with ARC headers on them here!
>> Bron Gondwana, CEO, FastMail Pty Ltd
>> dmarc mailing list
dmarc mailing list