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)
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
