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?