[dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-arc-protocol-21: (with COMMENT)

[Eric Rescorla <[e-mail]>]

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.