On 7/10/18 12:43 PM, Murray S. Kucherawy wrote:
RFC7601 doesn't require or encourage deletion of A-R fields in general. (The strongest word is "could".) If it's valid and possibly useful downstream, you can certainly keep it. It only says you have to delete stuff that's clearly a forgery.
I didn't go back and check the wording used in 7601 obviously. I was inferring from the language in 4.1.2, "are likely to be deleted".
- AS: I'm having trouble understanding what this is for. Why do we need another layer of signature on top of that in the AMS? Because the AS, signing only the ARC chain headers, provides a less fragile/more resilient mechanism for chain continuity. By scoping to just the ARC chain, we expect less collateral breakage than any signature which covers arbitrary headers and body.The point of signing the body in DKIM was to make sure that there was no opportunity to splice a different body onto a validly signed message. This was considered important when we discussed the l= (length) tag/value on DKIM signatures, because there was concern that an attacker could append content to a message with a valid signature. My concern with this is that since AS isn't signing the body but is being depended upon for message handling decisions, this might be exploited by an attacker. This needs, at a minimum, to be a security consideration.AMS is basically the same as DKIM-Signature, and so it covers body modifications. When you verify the seal, you must also verify the latest AMS, which in turn means the seal is invalidated as soon as someone changes the content.
Which goes back to my original question. If you need to check the AMS anyway, what additional purpose does the AS serve?
9.1 is not a security consideration, or at least it's not in expressed in terms of how an attacker might exploit ARC to cause problems with header size. I agree that this is not really a security issue - but it is a potential operational one. Where should this caution be moved do?I'm not sure there is a defined place. Perhaps an informational note in 4.3 where it's describing the chain as a whole would be an appropriate place for this.I disagree. If I can cause your MTA to crash because of oversized header fields, that's at least a denial of service attack. If I can cause your filter to crash because of oversized header fields and your MTA fails open, I can bypass whatever protections the filter offers.
In that case, I'm fine if this is expressed in terms of a security threat. But any ARC-specific nature to this threat is a marginal case; an attacker could do the same in most cases by just adding lots of garbage header fields.
13.2 Not clear to me why previous revisions of this draft are included as informative references. ARC-MULTI (IMO) should be included in this draft. ENHANCED-STATUS looks like a normative reference to me. Some of the references to 7601bis might also be normative; can these be changed to 7601 (non-bis)? The previous versions are cited because some of the implementations listed in section 12 were built to earlier versions and have not necessarily been vetted against the current version. With the removal of section 12 upon publication, those earlier versions can also be dropped. The references to 7601bis will be normative, but only once the updated document number is issued. I don't think that we can cite a "bis" as a normative reference.At publication, you shouldn't cite an Internet Draft at all since it will expire. Whether references are normative or informative doesn't depend on the status of the document, but on the nature of the reference. I'm under the impression that this document is ahead of 7601bis for publication. If it depends on things that are new in 7601bis, then it will need to wait for 7601bis to be published. Otherwise, suggest you make the references to 7601 instead.I disagree. I've had RFCs published that reference in-progress drafts, in one case one that never got published. But in this case, they would just hold this until 7601bis was also ready, and publish them as a cluster.
OK, it's possible that this has been done. But the important question is, does this draft need to wait for 7602bis to be published?
-Jim
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
