The Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-23

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.