The Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-23
Note: This ballot was opened for revision 18 and is now closed.
(Ben Campbell) Yes
Comment (2018-11-20 for -21)
Thanks for including the Experimental Considerations
Alexey Melnikov Yes
Adam Roach Yes
Comment (2018-11-20 for -21)
Thanks to everyone for the work that went into this document. I'm excited by
this experiment, and hope it eventually grows into something we can put on the
standards track.
---------------------------------------------------------------------------
id-nits reports:
** There are 3 instances of too long lines in the document, the longest one
being 15 characters in excess of 72.
---------------------------------------------------------------------------
§7.2:
> remote-ip[1]=10.10.10.13</comment>
Please consider using an IPv6 address here. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
In any case, please use an address from the ranges reserved by either RFC 5737
or (preferably) RFC 3849.
---------------------------------------------------------------------------
Appendix B:
> Received: from example.org (example.org [208.69.40.157])
...
> Received: from segv.d1.example (segv.d1.example [72.52.75.15])
...
> Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
...
> [208.69.40.157]) by clochette.example.org with ESMTP id
The two comments I made on §7.2 apply to these four IP addresses as well.Deborah Brungard No Objection
Alissa Cooper No Objection
(Spencer Dawkins) No Objection
Suresh Krishnan No Objection
(Eric Rescorla) No Objection
Comment (2018-11-21 for -21)
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.
Alvaro Retana No Objection
Martin Vigoureux No Objection
Benjamin Kaduk No Record
Comment (2018-11-21 for -21)
Section 3 Do we really need a trailer appended to the (new) BCP 14 boilerplate? Section 3.5 (I note that "Seal" is used in other IETF contents to enclude encryption, e.g., RFC 1508. I don't see a need for this usage to change, though.) Section 9.2 Are there any concerns about privacy relating to the possibility of using a tailored set of [ARC Sets inducing] DNS queries, to fingerprint/identify specific clients/recipients?