On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote: > As I went through the edits for > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 > I was unable to understand the value added by having the "arc.closest- > fail" listed in the AAR. Please read my examples again if the problem wasn't clear, because you don't get security by imagining the best cases where everyone behaves themselves, you get security by imagining that everybody is trying to get away with the worst abuses they can without being detected. Without a closest-fail from each step, or a similar way to determine changes, information about abuses gets lost along the chain, and the final receiver can't tell who modified the message along the way. > Looking back through the list archives, the idea for this pvalue seems > to have come up in mid-August, captured in this snippet:> > On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana > <[email protected]> wrote:>> __ >> >> On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote: >>> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana >>> <[email protected]> wrote:>>> > That seems like it would be enough to >>> fix that objection. An >>> > additional "first AMS failure" header at each hop would give you a >>> > list of who actually modified the message.>>> >>> arc.closest_fail has been defined to accomplish this. >> >> That looks great. It adds enough information that my other questions >> are basically efficiency concerns, which are not nothing, but at >> least ARC signing doesn't make things worse...> > It seems that Bron is advocating a change in the verify process where > by all AMS signatures would have to be checked rather than just the > most recent one. Going through the archives showed me that the > language in 5.2.1 should say "...the most recent AMS that fails to > validate..." rather than "...the most recent AS that fails to > validate..." but then the verifier actions would also need to be > updated in section 6 (steps 3+). Yes, it should say most recent AMS, not AS. All AS should always validate. > If we are only concerned with changes in the body of the message > which are being introduced by intermediaries, it seems like we could > just check for changes in the bh value between hops rather than > requiring each verifier to walk (possibly) the whole list of AMS > headers. No, that's bogus. The message is not the body, the message is body+subject+from+to. In particular, a bad actor intermediate could totally change the meaning of a message by changing the subject. Messages where the majority of meaning is in the subject definitely exist. Subject: Please clean out your stuff from the fridge
Body: Thanks, Bron. vs Subject: URGENT: your need to paypal $5000 to [email protected] TODAY or we will lose $IMPORTANT_CONTRACT Body: Thanks, Bron. Both have the same bh=, but they're very different messages. > Does this provide enough "bang for the buck" to make it worthwhile? or > should we cut out this field? If we cut the field, then ARC usage guidelines need to say "don't seal if you didn't change the message" or we're breaking the value of the chain. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd [email protected]
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
