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

[Kurt Andersen <[e-mail]>]

On Wed, Nov 21, 2018 at 6:16 AM Eric Rescorla <[e-mail]> wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-dmarc-arc-protocol-21: No Objection
>
> ----------------------------------------------------------------------
> 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?
>

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?


> 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.
>

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.


> 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.
>

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