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

Document: draft-ietf-dmarc-arc-protocol

(1) The RFC is marked "Experimental", and it is listed correctly.
This is the proper RFC.

(2)

Technical Summary:

    The Authenticated Received Chain (ARC) protocol provides an
    authenticated "chain of custody" for a message, allowing each entity
    that handles a message to see what entities have handled it before,
    and to see what the message's authentication assessment was at each step
    in the handling. This allows to convey original authentication
    assessments across trust boundaries.

Working Group Summary:

    The working group process was quite involved, and because this document
    is Experimental, there was active discussions on implementations and
    experiments that are detailed in the document. Additionally, an example is
    included in Appendix B to show a mock up of a message that has multiple
    ARC signatures.

Document Quality: 

    The document lists the existing implementations of the protocol, and
    appears to cover a broad spectrum of both puchased software as well as
    open source.

Personnel:

    Document Shepherd: Tim Wicinski
    Area Director:  Alexey Melnikov

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

    The Document Shepherd first did a technical review of the document; and
    followed that with an editorial review. There were several small
    editorial issues that were passed along to the authors, but do not
    affect the document itself.

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

    The Document Shepherd does not have any concerns about the depth or
    breath of reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    No other reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

    There are no concerns or issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    Authors have confirmed there are no known IPR disclosures.

(8) Has an IPR disclosure been filed that references this document?

    There are no IPR disclosures.

(9) How solid is the WG consensus behind this document?

    Consensus is strong, and is both broad and deep in terms of the
    working group.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

    No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    None needed

(13) Have all references within this document been identified as
either normative or informative?

    All references have been identified as normative or informative.
    The only concern is the Informative References refer to previous
    versions of this document.  This should not be a problem moving
    forward, but it could be addressed.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

    No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified.

    There are no new IANA registries created by this document.
    There are additions to existing registries, and the Document
    Shepherd's review confirms the registries are clearly identified,
    and the additions are consistent.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

[Ballot comment]
Section 3

Do we really need a trailer appended to the (new) BCP 14 boilerplate?

Section 3.5

(I note that "Seal" is used in other IETF contents to enclude
encryption, e.g., RFC 1508.  I don't see a need for this usage to
change, though.)

Section 9.2

Are there any concerns about privacy relating to the possibility of
using a tailored set of [ARC Sets inducing] DNS queries, to
fingerprint/identify specific clients/recipients?

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

[Ballot comment]
[I may not get to finish reading this by the telechat time, but noted in reading the DMARC charter that
  The working group will not develop additional mail authentication
  technologies, but may document authentication requirements that are
  desirable.
This work is not exactly an authentication technology, in that it just claims to allow additional
recording of existing authentication processing, but it does seem that such recorded results
might then be used as part of authentication decisions later down the line.  I assume everyone is
okay with this situation, based on ballot positions so far.]

[Ballot comment]

Thanks to everyone for the work that went into this document. I'm excited by
this experiment, and hope it eventually grows into something we can put on the
standards track.

---------------------------------------------------------------------------

id-nits reports:

  ** There are 3 instances of too long lines in the document, the longest one
    being 15 characters in excess of 72.

---------------------------------------------------------------------------

§7.2:

>      remote-ip[1]=10.10.10.13

Please consider using an IPv6 address here. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/

In any case, please use an address from the ranges reserved by either RFC 5737
or (preferably) RFC 3849.

---------------------------------------------------------------------------

Appendix B:

> Received: from example.org (example.org [208.69.40.157])
...
> Received: from segv.d1.example (segv.d1.example [72.52.75.15])
...
> Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
...
>    [208.69.40.157]) by clochette.example.org with ESMTP id


The two comments I made on §7.2 apply to these four IP addresses as well.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dmarc-arc-protocol-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the Email Authentication Result Names registry on the Email Authentication Parameters registry page located at:

https://www.iana.org/assignments/email-auth/

three, new values are to be registered as follows:

Auth Method(s): arc
Code: none
Specification: [ RFC-to-be Section 2.2 ]
Status: Active

Auth Method(s): arc
Code: pass
Specification: [ RFC-to-be Section 2.2 ]
Status: Active

Auth Method(s): arc
Code: fail
Specification: [ RFC-to-be Section 2.2 ]
Status: Active

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Email Authentication Methods registry also on the Email Authentication Parameters registry page located at:

https://www.iana.org/assignments/email-auth/

three, new values are to be registered as follows:

Method: arc
Definition: [ RFC-to-be ]
ptype: smtp
Property: client-ip
Value: IP address of originating SMTP connection
Status: active
Version: 1

Method: arc
Definition: [ RFC-to-be ]
ptype: header
Property: oldest-pass
Value: The instance id of the oldest validating AMS, or 0 if they all pass (see Section 5.2 of [ RFC-to-be ])
Status: active
Version: 1

Method: dkim
Definition: [ draft-ietf-dmarc-rfc7601bis ]
ptype: header
Property: s
Value: value of signature "s" tag
Status: active
Version: 1

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Permanent Message Header Field Registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

there are three registrations that will have their references changed to [ RFC-to-be ]:

Header field name: ARC-Seal
Applicable protocol: mail
Status: draft
Author/Change controller: IETF
Specification document(s): [ RFC-to-be ]
Related information: [RFC6376]

Header field name: ARC-Message-Signature
Applicable protocol: mail
Status: draft
Author/Change controller: IETF
Specification document(s): [ RFC-to-be ]
Related information: [RFC6376]

Header field name: ARC-Authentication-Results
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document(s): [ RFC-to-be ]
Related information: [ draft-ietf-dmarc-rfc7601bis ]

IANA Question --> Should the "Related Information" references simply be added to the "Reference" field in the Permanent Message Header Field Names registrations?

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the Enumerated Status Codes registry on the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry page located at:

https://www.iana.org/assignments/smtp-enhanced-status-codes/

a single, new registration is to be made as follows:

Code: X.7.29
Sample Text: ARC validation failure
Associated basic status code: 550
Description: This status code may be returned when a message fails multiple authentication checks, including ARC validation
Reference: [ RFC-to-be ]
Submitter: K. Andersen
Change controller: IESG

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-11-06):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, Barry Leiba , draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski , dmarc@ietf.org, alexey.melnikov@isode.com, dmarc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Authenticated Received Chain (ARC) Protocol) to Experimental RFC


The IESG has received a request from the Domain-based Message Authentication,
Reporting & Conformance WG (dmarc) to consider the following document: -
'Authenticated Received Chain (ARC) Protocol'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-11-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Authenticated Received Chain (ARC) protocol provides an
  authenticated "chain of custody" for a message, allowing each entity
  that handles the message to see what entities handled it before, and
  to see what the message's authentication assessment was at each step
  in the handling.

  ARC allows Internet Mail Handlers to attach assertions of message
  authentication assessment to individual messages.  As messages
  traverse ARC-enabled Internet Mail Handlers, additional ARC
  assertions can be attached to messages to form ordered sets of ARC
  assertions that represent the authentication assessment at each step
  of message handling paths.

  ARC-enabled Internet Mail Handlers can process sets of ARC assertions
  to inform message disposition decisions, to identify Internet Mail
  Handlers that might break existing authentication mechanisms, and to
  convey original authentication assessments across trust boundaries.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.

I have several comments about the document, mostly about incorrect classification of references as Informative. I will send my comments separately.
However I don't think this should delay IETF LC.

Document: draft-ietf-dmarc-arc-protocol

(1) The RFC is marked "Experimental", and it is listed correctly.
This is the proper RFC.

(2)

Technical Summary:

    The Authenticated Received Chain (ARC) protocol provides an
    authenticated "chain of custody" for a message, allowing each entity
    that handles a message to see what entities have handled it before,
    and to see what the message's authentication assessment was at each step
    in the handling. This allows to convey original authentication
    assessments across trust boundaries.

Working Group Summary:

    The working group process was quite involved, and because this document
    is Experimental, there was active discussions on implementations and
    experiments that are detailed in the document. Additionally, examples are
    included in Appendix B (XXX) to show a mock up of a message at each
    step in the chain.

Document Quality: 

    The document lists the existing implementations of the protocol, and
    appears to cover a broad spectrum of both puchased software as well as
    open source.

Personnel:

    Document Shepherd: Tim Wicinski
    Area Director:  Alexey Melnikov

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

    The Document Shepherd first did a technical review of the document; and
    followed that with an editorial review. There were several small
    editorial issues that were passed along to the authors, but do not
    affect the document itself.

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

    The Document Shepherd does not have any concerns about the depth or
    breath of reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    No other reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

    There are no concerns or issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    Authors have confirmed there are no known IPR disclosures.

(8) Has an IPR disclosure been filed that references this document?

    There are no IPR disclosures.

(9) How solid is the WG consensus behind this document?

    Consensus is strong, and is both broad and deep in terms of the
    working group.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

    No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    None needed

(13) Have all references within this document been identified as
either normative or informative?

    All references have been identified as normative or informative.
    The only concern is the Informative References refer to previous
    versions of this document.  This should not be a problem moving
    forward, but it could be addressed.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

    No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified.

    There are no new IANA registries created by this document.
    There are additions to existing registries, and the Document
    Shepherd's review confirms the registries are clearly identified,
    and the additions are consistent.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.