Eric Rescorla has entered the following ballot position for draft-ietf-dmarc-arc-protocol-21: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3829 These would be DISCUSS-worthy comments but this is an Experimental document so I am just making them comments. IMPORTANT S 9. > handlers for a message. This record may include Personally > Identifiable Information such as IP address(es) and domain names. > Such information is also included in existing non-ARC related header > fields such as the "Received" header fields. > > 9. Security Considerations You need to document what the semantics of a received message with an ARC Chain is. As I understand it, it's that the highest-numbered instance N vouches that: It processed a message with this body, a given authres, and ARC chains 1..N-1. And then instance N-1 vouches that it received a message with a given authres, and ARC chains 1..N-2, and so on. Is that correct? COMMENTS S 4.1.3. > > To preserve the ability to verify the integrity of a message, the > signature of the AMS header field SHOULD include any DKIM-Signature > header fields already present in the message. > > 4.1.3. ARC-Seal (AS) It would be useful to state the rationale here for why you have separate signatures for headers and body. S 7.2. > Through the collection of ARC-related data, an ADMD can identify > handling paths that have broken authentication. > > An Authenticated Received Chain allows an Internet Mail Handler to > potentially base decisions of message disposition on authentication > assessments provided by different ADMDs. "potentially base" seems pretty handwavy. As below, I think you need to provide some guidance about what on would actually do. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
