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

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Nov 2018 06:16:42 -0800

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.

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 21 Nov 2018 08:04:13 -0800

> draft-ietf-dmarc-arc-protocol-21: No Objection

Yes, that is correct, as long as you meant authres-payload. This was stated
earlier in the document, does it need to be repeated in section 9?

> separate signatures for headers and body.

They are not separate signatures for header and body. They are separate
signatures for ARC chain as an entity vs. the normal DKIM signing scope of
headers (excluding ARC) & body.

> to provide some guidance about what on would actually do.

Receivers are always free to do whatever they choose, including, in many
cases, completely ignoring information that is made available. We are
writing a separate document within the DMARC WG to cover usage
recommendations pertaining to ARC.

--Kurt Andersen

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Nov 2018 08:10:37 -0800

On Wed, Nov 21, 2018 at 8:04 AM Kurt Andersen <[email-masked]> wrote:

> Yes, that is correct, as long as you meant authres-payload. This was
> stated earlier in the document, does it need to be repeated in section 9?
>

Where is it stated?

> headers (excluding ARC) & body.

OK, so that would be useful to state.

> Receivers are always free to do whatever they choose, including,
>

That's theoretically true in all protocols and yet we routinely tell people
how they need to behave to be conformant. My problem here is that this
document needs to provide sufficient information to the reader to
understand how to interpret the ARC data and see what to do about that.

-Ekr

in many cases, completely ignoring information that is made available. We
> are writing a separate document within the DMARC WG to cover usage