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

[Eric Rescorla <[e-mail]>]

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

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

Where is it stated?



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

OK, so that would be useful to state.



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

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
> recommendations pertaining to ARC.
>



>
> --Kurt Andersen
>