Subject: [dmarc-ietf] ARC draft-10 Security Considerations - questions and request

From: Seth Blank <[email-masked]>
Date: Thu, 28 Dec 2017 17:21:09 -0800

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-13

Beyond my notes below, the Security Considerations section feels weak, and
like it should at least inherit DKIM's security considerations.
Additionally, there have definitely been items called out on this list
(like the ability to do an ARC replay attack) that are not yet represented.

Are there strong opinions about other items that should be in security
considerations? I'll be going through the list archives to see if I can
find orphaned items that should be included, but please SPEAK UP if there's
something obvious to you.

My concerns/questions:

13.1: I don't understand how this is a security consideration. However, it
might make a good "open question" in experimental considerations.

13.2: It should be noted that verifier caching of DNS responses renders
this type of attack weak, only systems that validate ARC Chains that do not
cache DNS responses will be susceptible to an attack here.

13.3: this doesn’t make sense as a security consideration, this is the same
warning as with SPF, DKIM, and DMARC, which are up front in those drafts
and not in security considerations (and is also front and center in the
initial paragraph of section 4).

That said, is it worth adding (or rewording 13.3) to make it clear that one
should "not blindly trust a passing ARC chain" because:

a) you have to trust all signatories

b) It’s possible that trusted systems don't properly authenticate messages,
so even with a legit ARC chain with sealers you trust, the message might
still never have authenticated in the first place (which is why you have
the AAR to inspect)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Dec 2017 09:35:19 -0800

> (like the ability to do an ARC replay attack) that are not yet represented.

ARC does inherit DKIM.  The single sentence of Section 13 itself does so.

> might make a good "open question" in experimental considerations.

It depends on the failure mode of modules that don't handle oversized
header properly.  If, say, a spam filter blows up on an oversized header
and the system fails open, the message will be delivered.

> cache DNS responses will be susceptible to an attack here.

If I want to attack sethblank.com, all I have to do is generate N messages
with "d=sethblank.com" and rotate the selector to be a random set of
strings.  That'll avoid caching.

> That said, is it worth adding (or rewording 13.3) to make it clear that
> one should "not blindly trust a passing ARC chain" because:
>
> b) It’s possible that trusted systems don't properly authenticate
> messages, so even with a legit ARC chain with sealers you trust, the
> message might still never have authenticated in the first place (which is
> why you have the AAR to inspect)
>

Sure.

-MSK