Subject: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Aug 2018 06:43:11 -0700

Continuing my review of: draft-ietf-dmarc-arc-protocol-16

NB:  These are comments, not demands. Use however is helpful...

> 4.  Protocol Elements

I keep thinking that it would help to have some summary text, possibly 
with a figure, that shows the role of individual header fields and sets 
of them.

My first inclination is to suggest putting it here, but perhaps it would 
actually be better to have it at the /end/ of this section, after each 
component has been defined.

(I'd offer some candidate text/figure, but I am not sure I have a solid 
enough sense of the details.)

> 4.1.  ARC Headers

   Headers -> Header Fields

(I feel compelled to constantly apologize that RFC 733 made the term be 
'header field' rather than 'header'...)

> 
>    ARC introduces three new header fields.  Syntax for new header fields
>    borrows heavily from existing specifications.  This document only
> 

    borrows heavily from -> adapts

> Andersen, et al.        Expires January 18, 2019                [Page 7]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    describes where ARC-specific changes in syntax and semantics differ
>    from existing specifications.
> 
> 4.1.1.  ARC-Authentication-Results (AAR)
> 
>    The ARC-Authentication-Results (AAR) header field records the message
>    authentication state as processed by an ARC-participating ADMD at
>    message arrival time.

I'll note my continuing concern for 'authentication state'...

> 
>    In General Concept terms, the AAR header field is where Evidence is
>    recorded by a Custodian.

The arguments against the chain of custody model and terminology have 
swayed me.  The operation of ARC is not strict enough or reliable enough 
to justify the model or terms, which means that using them sets 
expectations to high.

> 
>    The AAR header field is similar in syntax and semantics to an
>    Authentication-Results field [I-D-7601bis], with two (2) differences:
> 
>    o  the name of the header field itself;
> 
>    o  the presence of the "instance tag".  Additional information on the
>       "instance tag" can be found in Section 4.2.1.
> 
>    The formal ABNF for the AAR header field is:
> 
>    arc-info = instance [CFWS] ";" authres-payload
>    arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
> 
>    Because there is only one AAR allowed per ARC set, the AAR MUST
>    contain all authentication results from within the participating
>    ADMD, regardless of how many Authentication-Results headers are
>    attached to the message.
> 
> 4.1.2.  ARC-Message-Signature (AMS)
> 
>    The ARC-Message-Signature (AMS) header field allows an ARC-
>    participating ADMD to convey some responsibility (custodianship) for
>    a message and possible message modifications to future ARC-
>    participating Custodians.
> 
>    In General Concept terms, the AMS header field identifies a
>    Custodian.

The text after this provides some technical details about differences, 
but in terms of utility/purpose, how does this compare to doing a DKIM 
signature by this ADMD?  It's worth providing some comment about this.

> 
>    The AMS header field is similar in syntax and semantics to a DKIM-
>    Signature field [RFC6376], with three (3) differences:

   is similar in -> has the same

   to a -> as the

> 
>    o  the name of the header field itself;
> 
>    o  no version tag ("v") is defined for the AMS header field.  As
>       required for undefined tags (in [RFC6376]), if seen, a version tag
>       MUST be ignored;
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019                [Page 8]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    o  the presence of the "instance tag".  Additional information on the
>       "instance tag" can be found in Section 4.2.1.  The instance tag
>       replaces the DKIM "AUID" tag;
> 
>    o  when building the header field list to be signed, ARC-related
>       headers MUST be submitted to the hash function in increasing
>       instance order.

   header -> fields

> 
>    ARC places no requirements on the selectors and/or domains used for
>    the AMS header field signatures.
> 
>    The formal ABNF for the AMS header field is:
> 
>    arc-ams-info = instance [CFWS] ";" tag-list
>    arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
> 
>    To avoid unwanted invalidation of AMS signatures:
There are cases where invalidation is /wanted/???

Perhaps:

    To minimize the problem of AMS signature invalidation:

> 
>    o  AMS header fields are added by ARC-participating ADMDs as messages
>       exit the ADMD.  AMS header fields SHOULD be attached so that any
>       modifications made by the ADMD are included in the signature of
>       the AMS header field.
> 
>    o  Authentication-Results header fields MUST NOT be included in AMS
>       signatures as they are likely to be deleted by downstream ADMDs
>       (per [I-D-7601bis] Section 5).
> 
>    o  ARC-related header fields (ARC-Authentication-Results, ARC-
>       Message-Signature, ARC-Seal) MUST NOT be included in the list of
>       header fields covered by the signature of the AMS header field.
> 
>    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.

Arguably, including it/them does NOT alter integrity validation. i 
suspect /ever/.  At the least, be explicit about /what/ integrity is 
being maintain.

That is, the dkim signature provides a specific kind of integrity.  If 
it validates, that integrity is proved.  If it doesn't, it isn't. 
covering it by ARC doesn't affect either outcome.

> 
> 4.1.3.  ARC-Seal (AS)
> 
>    The ARC-Seal (AS) header field is the mechanism by which ARC-

    is a mechanism by which -> permits

>    participating ADMDs can verify the integrity of AAR header fields and

    can -> to

>    corresponding AMS header fields.
> 
>    In General Concept terms, the AS header field is how Custodians bind
>    Evidence into a Chain of Custody so that Validators can inspect
>    individual Evidence and Custodians.
> 
>    The AS header field is similar in syntax and semantics to DKIM-
>    Signatures [RFC6376], with the following differences:
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019                [Page 9]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    o  the presence of the "instance tag".  Additional information on the
>       "instance tag" can be found in Section 4.2.1.
> 
>    o  the signature of the AS header field does not cover the body of
>       the message and therefore there is no 'bh' tag.  The signature of
>       the AS header field only covers specific header fields as defined
>       in Section 5.1.1.
> 
>    o  no body canonicalization is performed as the AS signature does not
>       cover the body of a message.
> 
>    o  only "relaxed" header canonicalization ([RFC6376] section 3.4.2)
>       is used.
> 
>    o  the only supported tags are "i" (from Section 4.2.1 of this
>       document), and "a", "b", "d, "s", "t" from [RFC6376] Section 3.5.
>       Note especially that the DKIM "h" tag is NOT allowed and if found,
>       MUST result in a cv status of "fail" (for more information see
>       Section 5.1.1);
> 
>    o  an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
>       definition) is used to communicate Chain Validation Status to
>       subsequent ADMDs.
> 
>    ARC places no requirements on the selectors and/or domains used for
>    the AS header field signatures.

what does this mean? how is it relevant?

> 
>    The formal ABNF for the AS header field is:
> 
>    arc-as-info = instance [CFWS] ";" tag-list
>    arc-seal = "ARC-Seal:" [CFWS] arc-as-info
> 
> 4.2.  ARC Set
> 
>    An "ARC Set" is a single collection of three ARC Headers (AAR, AMS,
>    and AS).  ARC Headers of an ARC Set share the same "instance" value.
> 
>    By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set
>    to a message.  A description of how Sealers add an ARC Set to a
>    message is found in Section 5.1.
> 
> 4.2.1.  Instance Tags
> 
>    Instance tags describe which ARC Headers belong to an ARC Set. Each
>    ARC Header of an ARC Set shares the same instance tag value.
> 
>    Instance tag values are integers that begin at 1 and are incremented
>    by each addition of an ARC Set. Through the incremental values of
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 10]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    instance tags, an ARC Validator can determine the order in which ARC
>    Sets were added to a message.
> 
>    Instance tag values can range from 1-50 (inclusive).
> 
>    _INFORMATIONAL:_ The upper limit of 50 was picked based on some
>    initial observations reported by early working group members with a
>    safety margin multiple added on top to support the vast majority of
>    all intermediary mail flows.

Rather than citing a wg process, document the technical, administrative 
and/or operation concerns, benefits, etc. that justify the choice.

> 
>    Valid ARC Sets MUST have exactly one instance of each ARC Header
>    field (AAR, AMS, and AS) for a given instance value and signing
>    algorithm.
> 
>    _INFORMATIONAL:_ Initial development of ARC is only being done with a
>    single allowed signing algorithm, but parallel work in the DCRUP
>    working group is expanding that.  For handling multiple signing
>    algorithms, see [ARC-MULTI].

As a rule, RFCs should not refer to parallel activities, since the 
reference is soon to become stale and wrong.

If additional signing algorithms are anticipated -- and of course they 
should be -- then define a means for extending what is permitted, noting 
that the initial algorithm is provided to ensure basic, initial 
interoperability.

> 
> 4.3.  Authenticated Received Chain
> 
>    An Authenticated Received Chain is an ordered collection of ARC Sets.
>    As ARC Sets are enumerated sets of ARC Headers, an Authenticated
>    Received Chain represents the output of message authentication state
>    along the handling path of ARC-enabled processors.
> 
>    Results of message authentication processing along each step of the
>    ARC-enabled handling path is present in an Authenticated Received
>    Chain in the form of AAR header fields.  The ability to verify the
>    identity of message handlers and the integrity of message content is
>    provided by AMS header fields.  AS header fields allow messages
>    handlers to validate the assertions, order and sequence of the
>    Authenticated Received Chain itself.
> 
>    In General Concept terms, an Authenticated Received Chain represents
>    a message's Chain of Custody.  Validators can consult a message's
>    Chain of Custody to gain insight regarding each Custodian of a
>    message and the Evidence collected by each Custodian.
> 
> 4.4.  Chain Validation Status
> 
>    The state of the Authenticated Received Chain at a specific
>    processing step is called the "Chain Validation Status".  Chain
>    Validation Status information is communicated in several ways:
> 
>    o  the AS header field in the "cv" tag, and
> 
>    o  as part of Authentication-Results and AAR headers.
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 11]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    Chain Validation Status has one of three possible values:
> 
>    o  none: There was no Authenticated Received Chain on the message
>       when it arrived for validation.  Typically this occurs when a
>       message is received directly from a message's original Message
>       Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
>       upstream Internet Mail Handler that is not participating in ARC
>       handling.
> 
>    o  fail: The message contains an Authenticated Received Chain whose
>       validation failed.
> 
>    o  pass: The message contains an Authenticated Received Chain whose
>       validation succeeded.
> 
> 5.  Protocol Actions
> 
>    ARC-enabled Internet Mail Handlers generally act as both ARC Sealers
>    (when sending messages) and ARC Validators (when receiving messages).

generally?  that statement is worth expanding.  When are they only one? 
When are they only the other? Is it possible to do neither and still be 
an Arc-enabled IM handler?  What is the benefit of doing only one?

> 5.1.  Sealer Actions
> 
>    To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC
>    header fields AAR, AMS, and AS) to a message.  All ARC header fields
>    in an ARC Set share the same instance tag value.
> 
>    To perform Sealing (aka to build and attach a new ARC Set), the
>    following actions must be taken by an ARC Sealer when presented with
>    a message:
> 
>    1.  All message modifications (including adding DKIM-Signatures) MUST
>        be performed before Sealing.

Does it include adding Received fields?  Given how common the action, 
it's worth citing it explicitly.

> 
>    2.  Calculate the instance value: if the message contains an

   contains -> already contains

>        Authenticated Received Chain, the instance value is 1 more than
>        the highest instance number found in the Authenticated Received
>        Chain.  If no Authenticated Received Chain exists, the instance
>        value is 1.
> 
>    3.  Using the calculated instance value, generate and attach to the
>        message in the following order:

4-6 are subordinate to 3.  They should be sub-numbered. Alternatively 
(and probably better) is to get rid of 3 and mildly modify 4, 5 and 6 to 
have the 'generate and attach' verbiage directly...

> 
>    4.  An ARC-Authentication-Results header field as defined in
>        Section 4.1.1.
> 
>    5.  An ARC-Message-Signature header field as defined in
>        Section 4.1.2.
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 12]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    6.  An ARC-Seal header field using the AS definition found in
>        Section 4.1.3, the method described in Section 5.1.1, and the
>        Chain Validation Status as determined during ARC validation.
> 
> 5.1.1.  Header Fields To Include In ARC-Seal Signatures
> 
>    The signature of an AS header field signs a specific canonicalized

delete 'specific'.

>    form of the ARC Set header values.  The ARC set header values are
>    supplied to the hash function in increasing instance order, starting

'the hash function'.  Not clear to be that which hash function will be 
clear to the reader, especially since there is more than one in ARC, 
isn't there --  one for arc signature and one for arc seal?

>    at 1, and include the ARC Set being added at the time of Sealing the
>    message.
> 
>    Within an ARC Set, header fields are supplied to the hash function in
>    the following order:
> 
>    1.  ARC-Authentication-Results
> 
>    2.  ARC-Message-Signature
> 
>    3.  ARC-Seal
> 
>    The ARC-Seal is generated in a manner similar to when DKIM-Signatures
>    are added to messages ([RFC6376], section 3.7).

Not sure how the above sentence is supposed to be used, especially in 
the middle of the detailed procedural specification.

> 
>    Note that when an Authenticated Received Chain has failed validation,
>    the signing scope for the ARC-Seal is modified (see Section 5.1.2).

This sounds like it should be more than a terse, offhand 'note' and it 
seems to imply that the reader should already be aware of the point.

> 
> 5.1.2.  Marking and Sealing "cv=fail" (Invalid) Chains
> 
>    In the case of a failed Authenticated Received Chain, the header
>    fields included in the signature scope of the AS header field b=
>    value MUST only include the ARC Set headers created by the MTA which
>    detected the malformed chain, as if this newest ARC Set was the only
>    set present.
> 
>    _INFORMATIONAL_: This approach is mandated to handle the case of a
>    malformed or otherwise invalid Authenticated Received Chain.  There
>    is no way to generate a deterministic set of AS header fields
>    (Section 5.1.1) in most cases of invalid chains.
> 
> 5.1.3.  Only One Authenticated Received Chain Per Message
> 
>    A message can have only one Authenticated Received Chain on it at a
>    time.  Once broken, the chain cannot be continued, as the chain of
>    custody is no longer valid and responsibility for the message has
>    been lost.  For further discussion of this topic and the designed
>    restriction which prevents chain continuation or re-establishment,
>    see [ARC-USAGE].
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 13]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
> 5.1.4.  Broad Ability to Seal
> 
>    ARC is not solely intended for perimeter MTAs.  Any mediator
>    ([RFC5598], section 5) that modifies a message may Seal its own
>    changes.  For additional information, see Section 7.1.
> 
> 5.1.5.  Sealing is Always Safe
> 
>    The utility of an Authenticated Received Chain is limited to very
>    specific cases.  Authenticated Received Chains are designed to
>    provide additional information to an Internet Mail Handler when
>    evaluating messages for delivery in the context of authentication
>    failures.  Specifically:
> 
>    o  Properly adding an ARC Set to a message does not damage or
>       invalidate an existing Authenticated Received Chain.
> 
>    o  Sealing an Authenticated Received Chain when a message has not
>       been modified does not negatively affect the chain.
> 
>    o  Validating a message exposes no new threat vectors (see
>       Section 9).
> 
>    o  An ADMD may choose to Seal all inbound messages whether or not a
>       message has been modified or will be retransmitted.
> 
> 5.1.6.  Signing vs Sealing
> 
>    Signing is the process of affixing a digital signature to a message
>    as a header, such as when a DKIM-Signature (as in [RFC6376] section
>    2.1), or an AMS or AS is added.  Sealing is when an ADMD affixes a
>    complete and valid ARC Set to a message creating or continuing an
>    Authenticated Received Chain.

This paragraph should not be buried deep here.  It should probably be at 
the beginning of 5, or a similar 'introductory' place.

I'm starting to wonder about whether the term should be 'seal' or 'ARC 
seal'.  Here's my concern:  'signing' is a well-established, generic 
term.  'Sealing' is not.  Sealing applies only to ARC; the term is being 
created here.  There is less likelihood of confusion about the term if 
it is always formally referred to as 'ARC Sealing', because that will 
always make clear the context for its use.

BTW, do a complete pass over the doc, looking for 'header' and check 
whether it should actually be 'field' or 'header field'...

> 
> 5.2.  Validator Actions
> 
>    A validator performs the following steps, in sequence, to process an
>    Authenticated Received Chain.  Canonicalization, hash functions, and
>    signature validation methods are imported from [RFC6376] section 5.
> 
>    1.  Collect all ARC Sets currently attached to the message.  If there

break this into a list of sub-steps/-conditions

>        are none, the Chain Validation Status is "none" and the algorithm
>        stops here.  The maximum number of ARC Sets that can be attached
>        to a message is 50.  If more than the maximum number exist the
>        Chain Validation Status is "fail" and the algorithm stops here.
>        In the following algorithm, the maximum ARC instance value is
>        referred to as "N".
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 14]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    2.  If the Chain Validation Status of the highest instance value ARC
>        Set is "fail", then the Chain Validation status is "fail" and the
>        algorithm stops here.
> 
>    3.  Validate the structure of the Authenticated Received Chain.  A
>        valid ARC has the following conditions:
> 
>        1.  Each ARC Set MUST contain exactly one each of the three ARC
>            header fields (AAR, AMS, and AS).
> 
>        2.  The instance values of the ARC Sets MUST form a continuous
>            sequence from 1..N with no gaps or repetition.
> 
>        3.  The "cv" value for all ARC-Seal header fields must be non-

"non-failing" is not a listed value. I think an acceptable for of what 
you want to say:

       Each ARC-Seal MUST NOT have a "cv" value of "fail".

>            failing.  For instance values > 1, the value must be "pass".
>            For instance value = 1, the value must be "none".

    must -> MUST

> 
>        *  If any of these conditions are not met, the Chain Validation
>           Status is "fail" and the algorithm stops here.
> 
>    4.  Validate the AMS with the greatest instance value (most recent).
>        If validation fails, then the Chain Validation Status is "fail"
>        and the algorithm stops here.
> 
>    5.  _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by
>        validating each prior AMS beginning with the N-1 and proceeding
>        in decreasing order to the AMS with the instance value of 1:

why do this?

i gather some of the following are subordinate to 5?

> 
>    6.  If an AMS fails to validate (for instance value "M"), then set
>        the oldest-pass value to the lowest AMS instance value which
>        passed (M+1) and go to the next step (there is no need to check
>        any other (older) AMS headers).  This does not affect the
>        validity of the Authenticated Received Chain.
> 
>    7.  If all AMS headers verify, set the oldest-pass value to zero (0).
> 
>    8.  Validate each AS beginning with the greatest instance value and
>        proceeding in decreasing order to the AS with the instance value
>        of 1.  If any AS fails to validate, the Chain Validation Status
>        is "fail" and the algorithm stops here.
> 
>    9.  If the algorithm reaches this step, then the Chain Validation
>        Status is "pass", and the algorithm is complete.
> 
>    The end result of this Validation algorithm is added into the
>    Authentication-Results header for the ADMD.
> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 15]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    As with a failing DKIM signature ([RFC6376] section 6.3), a message
>    with a failing Authenticated Received Chain MUST be treated the same
>    as a message with no Authenticated Received Chain.

   fail"ing"?

I think you mean DKIM signature validation failure.

> 
>    _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
>    Received Chain can use that information as part of a wider handling
>    context.  ARC adoption cannot be assumed by intermediaries; many
>    intermediaries will continue to modify messages without adding ARC
>    Seals.
> 
> 5.2.1.  All Failures Are Permanent
> 
>    Authenticated Received Chains represent the traversal of messages
>    through one or more intermediaries.  All errors, including DNS
>    failures, become unrecoverable and are considered permanent.
> 
>    Any error Validating an Authenticated Received Chain results in a
>    failed Chain Validation Status.  For further discussion of this topic
>    and the design restriction which prevents chain continuation or re-
>    establishment, see [ARC-USAGE].
> 
> 5.2.2.  Responding to ARC Validation Failures During the SMTP
>         Transaction
> 
>    If an ARC Validator determines that the incoming message fails
>    authentication checks (potentially including ARC validation), the
>    Validator MAY signal the breakage through the extended SMTP response
>    code 5.7.7 [RFC3463] "message integrity failure" [ENHANCED-STATUS]
>    and corresponding SMTP response code.
> 
> 5.3.  Result of Validation
> 
>    An Authenticated Received Chain with a Chain Validation Status of
>    "pass" allows Internet Mail Handlers to ascertain:
> 
>    o  all ARC-participating ADMDs that claim responsibility for handling
>       (and possibly modifying) the message in transit;
> 
>    o  the authentication state of the message as perceived by each ADMD
>       (from Authentication-Results header fields).
> 
>    Given this information, handlers can inform local policy decisions
>    regarding disposition of messages that experience authentication
>    failure due to intermediate processing.

  5.3 isn't really a results specification.  It seems more like a useful 
summary of the tool's value proposition.

> 
> 
> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 16]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
> 6.  Communication of Validation Results
> 
>    Chain Validation Status (described in Section 4.4) is communicated
>    via Authentication-Results (and AAR) headers using the auth method
>    "arc".  This auth method is described in Section 10.1.
> 
>    If necessary data is available, the ptypes and properties defined in
>    Section 10.2 SHOULD be recorded in an Authentication-Results header
>    field:
> 
>    o  smtp.client-ip - The connecting client IP address from which the
>       message is received.

this seems such a large privacy concern, I question allowing it here. 
(This highlights the difference between passing information inside an 
enterprise, vs. over the open Internet, across administrations.)

> 
>    o  header.oldest-pass - The instance number of the oldest AMS that
>       still validates, or 0 if all pass.
> 
>    Upon Sealing of a message, this Authentication-Results information
>    along with all other Authentications-Results added by the ADMD will
>    be recorded into the AAR as defined in section Section 4.1.1.
> 
>    In General Concept terms, the information recorded in the ARC-
>    Authentication-Results header field is the Evidence that gets
>    attached to a message.

1. Don't capitalize GC

2. Each of these summary statements is better put much earlier.

> 
> 7.  Use Cases
> 
>    This section explores several messaging handling use cases that are
>    addressed by ARC.
> 
> 7.1.  Communicate Authentication Results Across Trust Boundaries
> 
>    When an intermediary ADMD adds an ARC Set to a message's
>    Authenticated Received Chain (or creates the initial ARC Set), the
>    ADMD communicates authentication state to the next ADMD in the
>    message handling path.

   to the next ARC-participating ADMD...

> 
>    If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
>    be used to bridge administrative boundaries.

This use case really isn't a use case, IMO. Rather, it is a basic 
observation about the nature and purpose of ARC.

> 
> 7.1.1.  Message Scanning Services
> 
>    Message services are available to perform anti-spam, anti-malware,
>    and anti-phishing scanning.  Such services typically remove malicious
>    content, replace HTTP links in messages with sanitized links, and/or
>    attach footers to messages advertising the abilities of the message
>    scanning service.  These modifications almost always break signature-
>    based authentication (such as DKIM).
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 17]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    Scanning services typically require clients to point MX records of an
>    Internet domain to the scanning service.  Messages destined for the
>    Internet domain are initially delivered to the scanning service.
>    Once scanning is performed, messages are then routed to the client's
>    own mail handling infrastructure.  Re-routing messages in this way
>    almost always breaks path-based authentication (such as SPF).
> 
>    Message scanning services can attach Authenticated Received Chains to
>    messages to communicate authentication results into client ADMDs.
>    Clients can then benefit from the message scanning service while
>    processing messages as if the client's infrastructure were the
>    original destination of the Internet domain's MX record.

A message scanning service has a tight relationship with the receiving 
ADMD.  In fact they are arguably /part/ of the receiving ADMD, in terms 
of trust among actors.  Hence I don't understand they they need ARC. 
They do all of the assessment work.  Why can't they just attach a normal 
auth-results field?

> 
> 7.1.2.  Multi-tier MTA Processing
> 
>    Large message processing infrastructure is often divided into several
>    processing tiers that can break authentication information between
>    tiers.  For example, a large site may maintain a cluster of MTAs
>    dedicated to connection handling and enforcement of IP-based
>    reputation filtering.  A secondary cluster of MTAs may be dedicated
>    and optimized for content-based processing of messages.
> 
>    Authenticated Received Chains can be used to communicated
>    authentication state between processing tiers.

Again, this is inside an enterprise's operation - a single ADMD - where 
the trust of actors should be quite high. Why is ARC needed here, rather 
than normal Auth-Results?

> 
> 7.1.3.  Mailing Lists
> 
>    Mailing lists resend posted messages to subscribers.  A full

   re-send posted messages ->  take delivery of messages and re-post them

'send' is not precise enough here.

>    description of authentication-related mailing list issues can be
>    found in [RFC7960] Section 3.2.3.
> 
>    Mailing list services can implement ARC to convey the original
>    authentication state of posted messages sent to the list's subscriber
>    base.  The ADMDs of the mailing list subscribers can then use the
>    Authenticated Received Chain to determine the authentication state of
>    the original message before mailing list handling.
> 
> 7.2.  Inform Message Disposition Decisions
> 
>    ARC functionality allows Internet Mail Handlers to reliably identify
>    intermediary ADMDs and for ADMDs to expose authentication state that
>    can survive additional intermediary handling.

This seems a highly redundant paragraph.

> 
>    Intermediaries often break authentication through content
>    modification, interfere with path-based authentication (such as SPF),
>    and strip authentication results (if an MTA removes Authentication-
>    Results headers).
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 18]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    Authenticated Received Chains allow ARC Validators to:
> 
>    1.  identify ARC-enabled ADMDs that break authentication while
>        processing messages;
> 
>    2.  gain extended visibility into the authentication-preserving
>        abilities of ADMDs that relay messages into ARC-enabled ADMDs.
> 
>    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
>    state provided by different ADMDs.
> 
> 7.2.1.  DMARC Local Policy Overrides
> 
>    DMARC introduces a policy model where Domain Owners can request email
>    receivers to reject or quarantine messages that fail DMARC alignment.
>    Interoperability issues between DMARC and indirect email flows are
>    documented in [RFC7960].
> 
>    Authenticated Received Chains allow DMARC processors to consider
>    authentication states provided by other ADMDs.  As a matter of local
>    policy, a DMARC processor may choose to accept the authentication

    may -> MAY

>    state provided by an Authenticated Received Chain when determining if
>    a message is DMARC compliant.
> 
>    When an Authenticated Received Chain is used to determine message
>    disposition, the DMARC processor can communicate this local policy
>    decision to Domain Owners as described in Section 7.2.2.
> 
> 7.2.2.  DMARC Reporting
> 
>    DMARC-enabled receivers indicate when ARC Validation influences
>    DMARC-related local policy decisions.  DMARC reporting of ARC-
>    influenced decisions is accomplished by adding a local_policy comment
>    containing a list of data discovered during ARC Validation, which at
>    a minimum includes:
> 
>    o  the Chain Validation Status,
> 
>    o  the domain and selector for each AS,
> 
>    o  the originating IP address from the first ARC Set:

a local policy comment /where/?  according to what specification for 
such comments?

> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 19]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    EXAMPLE:
> 
>    <policy_evaluated>
>      <disposition>none</disposition>
>      <dkim>fail</dkim>
>      <spf>fail</spf>
>      <reason>
>       <type>local_policy</type>
>       <comment>arc=pass ams[2].d=d2.example ams[2].s=s1
>         as[2].d=d2.example as[2].s=s2 as[1].d=d1.example
>         as[1].s=s3 client-ip[1]=10.10.10.13</comment>
>      </reason>
>    </policy_evaluated>
> 
>    In the above example DMARC XML reporting fragment, data relating to
>    specific validated ARC Sets are enumerated using array syntax (eg,
>    "ams[2]" means AMS header field with instance value of 2). d2.example
>    is the Sealing domain for ARC Set #2 (i=2) and d1.example is the
>    Sealing domain for ARC Set #1 (i=1).
> 
>    Depending on the reporting practices of intermediate message
>    handlers, Domain Owners may receive multiple DMARC reports for a
>    single message.  DMARC report processors should be aware of this
>    behaviour and make the necessary accommodations.
> 
> 8.  Privacy Considerations
> 
>    The Authenticated Received Chain provides a verifiable record of the
>    handlers for a message.  This record may include Personally
>    Identifiable Information such as IP address and domain names.  Such
>    information is also including in existing header fields such as the
>    "Received" header field.
> 
> 9.  Security Considerations
> 
>    The Security Considerations of [RFC6376] and [I-D-7601bis] apply
>    directly to this specification.
> 
>    As with other domain authentication technologies (such as SPF, DKIM,
>    and DMARC), ARC makes no claims about the semantic content of
>    messages.
> 
> 9.1.  Increased Header Size
> 
>    Inclusion of Authenticated Received Chains into messages may cause
>    issues for older or constrained MTAs due to increased total header
>    size.  Large header blocks, in general, may cause failures to deliver

header /field/?

> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 20]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    or other outage scenarios for such MTAs.  ARC itself would not cause
>    problems.
> 
> 9.2.  DNS Operations
> 
>    The validation of an Authenticated Received Chain composed of N ARC
>    Sets can require up to 2*N DNS queries (not including any DNS
>    redirection mechanisms which can increase the total number of
>    queries).  This leads to two considerations:
> 
>    1.  An attacker can send a message to an ARC participant with a
>        concocted sequence of ARC Sets bearing the domains of intended
>        victims, and all of them will be queried by the participant until
>        a failure is discovered.  The difficulty of forging the signature
>        values should limit the extent of this load to domains under
>        control of the attacker.  Query traffic pattern analysis may
>        expose information about downstream validating ADMD
>        infrastructure.
> 
>    2.  DKIM only performs one DNS query per signature, while ARC can
>        introduce many (per chain).  Absent caching, slow DNS responses
>        can cause SMTP timeouts; and backlogged delivery queues on
>        Validating systems.  This could be exploited as a DoS attack.
> 
> 9.3.  Message Content Suspicion

      ARC authenticates the identity of some email handling actors.  It 
does not make any assessment of their trustworthiness.

> 
>    Recipients are cautioned to treat messages bearing Authenticated
>    Received Chains with the same suspicion applied to all other
>    messages.  This includes appropriate content scanning and other
>    checks for potentially malicious content.
> 
>    Just as passing message authentication is not an indication of
>    message safety, forwarding that information through the mechanism of
>    ARC is also not an indication of message safety.  Even if all ARC-
>    enabled ADMDs are trusted, ADMDs may have become compromised, may
>    miss unsafe content, or may not properly authenticate messages.
> 
> 9.4.  Message Sealer Suspicion
> 
>    Recipients are cautioned to treat every Sealer of the ARC Chain with
>    suspicion.  Just as with a validated DKIM signature, responsibility
>    for message handling is attributed to the signing domain, but whether
>    or not that signer is a malicious actor is out of scope of the
>    authentication mechanism.  Since ARC aids message delivery in the
>    event of an authentication failure, ARC Sealers should be treated
>    with suspicion, so that a malicious actor cannot Seal spam or other
>    fraudulent messages to aid their delivery, too.
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 21]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
> 9.5.  Replay Attacks
> 
>    Since ARC inherits heavily from DKIM, it has similar attack vectors.
>    In particular, the Replay Attack described in [RFC6376] section 8.6
>    is potentially amplified by ARC's chained statuses.  In an ARC replay
>    attack, a malicious actor would take an intact and passing ARC Chain,
>    and then resend it to many recipients without making any
>    modifications that invalidate the latest AMS or AS.  The impact to a
>    receiver would be more DNS lookups and signature evaluations.  This
>    scope of this attack can be limited by caching DNS queries and
>    following the same signing scope guidance from [RFC6376] section
>    5.4.1.
> 
> 10.  IANA Considerations
> 
>    [[ *Note to the RFC Editors:* "dkim - header - s" is defined both
>    here and in [I-D-7601bis].  Please delete the overlap from whichever
>    document goes through the publication process after the other. ]]

This directive suggests a problem in clarity about document 
relationship.  This happens often in IETF specifications, where 
documents mutually cross reference, rather than establishing a clear 
hierarchical relationship.  Very rarely, documents really are co-equal. 
I think this is /not/ such a case.

My view is that rfc760bis has higher referential precedence and should 
therefore be the place for the cited definition.  The ARC document 
should inherit that definition.

> 
>    This draft introduces three new headers fields and updates the Email
>    Authentication Parameters registry with one new authentication method
>    and several status codes.
> 
> 10.1.  Email Authentication Results Names Registry Update
> 
>    This draft adds one Auth Method with three Codes to the IANA "Email
>    Authentication Result Names" registry:
> 
>    o  Auth Method : arc
>       Code: "none", "pass", "fail"
>       Specification: [I-D.ARC] 2.2
>       Status: active
> 
> 10.2.  Email Authentication Methods Registry Update
> 
>    This draft adds several new items to the Email Authentication Methods
>    registry, most recently defined in [I-D-7601bis]:
> 
>    o  Method: arc
>       Definition: [I-D.ARC]
>       ptype: smtp
>       Property: client-ip
>       Value: IP address of originating SMTP connection
>       Status: active
>       Version: 1
> 
>    o  Method: arc
>       Definition: [I-D.ARC]
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 22]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>       ptype: header
>       Property: oldest-pass
>       Value: The instance id of the oldest validating AMS, or 0 if they
>       all pass (see Section 5.2)
>       Status: active
>       Version: 1
> 
>    o  Method: dkim
>       Definition: [RFC6376]
>       ptype: header
>       Property: s
>       Value: value of signature "s" tag
>       Status: active
>       Version: 1
> 
> 10.3.  Definitions of the ARC header fields
> 
>    This specification adds three new header fields to the "Permanent
>    Message Header Field Registry", as follows:
> 
>    o  Header field name: ARC-Seal
>       Applicable protocol: mail
>       Status: draft
>       Author/Change controller: IETF
>       Specification document(s): [I-D.ARC]
>       Related information: [RFC6376]
> 
>    o  Header field name: ARC-Message-Signature
>       Applicable protocol: mail
>       Status: draft
>       Author/Change controller: IETF
>       Specification document(s): [I-D.ARC]
>       Related information: [RFC6376]
> 
>    o  Header field name: ARC-Authentication-Results
>       Applicable protocol: mail
>       Status: standard
>       Author/Change controller: IETF
>       Specification document(s): [I-D.ARC]
>       Related information: [I-D-7601bis]
> 
> 11.  Experimental Considerations
> 
>    The ARC protocol is designed to address common interoperability
>    issues introduced by intermediate message handlers.  Interoperability
>    issues are described in [RFC6377] and [RFC7960].
> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019               [Page 23]
> 
>  
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    As the ARC protocol is implemented by intermediary handlers over
>    time, the following should be evaluated in order to determine the
>    success of the protocol in accomplishing the intended benefits.
> 
> 11.1.  Success Consideration
> 
>    In an attempt to deliver legitimate messages that users desire, many
>    receivers use heuristic-based methods to identify messages that
>    arrive via indirect delivery paths.
> 
>    ARC will be a success if the presence of Authenticated Received
>    Chains allows for improved decision making when processing legitimate
>    messages.

+1

> 
> 11.2.  Failure Considerations
> 
>    ARC should function without introducing significant new vectors for
>    abuse (see Section 9).  If unforseen vectors are enabled by ARC, then

    unforeseen

>    this protocol will be a failure.  Note that weaknesses inherent in
>    the mail protocols ARC is built upon (such as DKIM replay attacks and
>    other known issues) are not new vectors which can be attributed to
>    this specification.
> 

/d

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Thu, 2 Aug 2018 09:07:59 -0700

> NB:  These are comments, not demands. Use however is helpful...

Dave, thanks for these comments. I've quickly scanned your notes and nearly
everything makes sense.

I'll go through the document and make the changes you've recommended over
the next day or so, and reply to this thread *where I have NOT* followed
your suggestions so further conversation can be focused on just those areas.

---

From: Brandon Long <[email-masked]>
Date: Fri, 3 Aug 2018 10:16:30 -0700

> Continuing my review of: draft-ietf-dmarc-arc-protocol-16

[snip]

> enterprise, vs. over the open Internet, across administrations.)

It is true that the privacy aspects of IP addresses are more concerning
than they have been,
but they also continue to be widely used in email message headers.

For this particular case, the IP is the IP of the sending server, not the
actual client.  Perhaps that
means the name is poorly chosen.  Perhaps smtp.remote-ip?  The IP of the
sending server
doesn't seem nearly as privacy sensitive as the IP of the sending user.
Some folks have brought up
that there may still be some geographic hints from this if the sending
service has servers in multiple regions,
but that's a much smaller privacy concern that I think is out-weighed by
the utility of having it here.  Especially
considering that it's already in the Received and Received-SPF headers.

Also, it is obviously optional, is SHOULD the wrong choice?

I guess there is a slight increase over the existing uses in that the value
is signed and therefore has more signal than the
other uses which could all be faked.  That seems to point more to the
"plausible deniability" privacy points, which arguably DKIM and ARC make
more challenging (ie, with the Clinton email leaks, the Gmail ARC signature
proved the message was intact as Gmail received it, and the DKIM signature
proved the message was sent by the campaign).  I don't think there is
consensus on that type of privacy.

For our internal design docs, we'd certainly highlight these things in the
privacy section and the separate privacy design doc, I'm not sure where
this would go in an rfc, the security section?  Or just a privacy section?

Brandon

---

From: Dave Crocker <[email-masked]>
Date: Fri, 3 Aug 2018 11:04:43 -0700

> but they also continue to be widely used in email message headers.

At a minimum, I suggest clear and relatively forceful language, making 
clear the privacy concerns.  (Privacy is new enough and, frankly, fuzzy 
enough as a technical topic, to warrant the redundancy I usually argue 
against...)

> For this particular case, the IP is the IP of the sending server, not 
> the actual client.  Perhaps that

oh.  yeah.  'client' seems the right technical term, absent a much 
longer string like 'initiating' (and I am not sugesting it.)

Perhaps change the explanatory text to something like:

    The address of the initiating SMTP server, from which the message is 
being relayed.

> service has servers in multiple regions,

That highlights the challenges of all things labeled 'privacy concern'. 
And it's why I think noting issues where they occur AND summarized in a 
privacy considerations section is warranted.

> Also, it is obviously optional, is SHOULD the wrong choice?

Yes.  The semantics of should is 'must do this, unless you are extremely 
careful and know exactly what you are doing'...

So MAY is probably the right choice.

d/

---

From: Seth Blank <[email-masked]>
Date: Fri, 3 Aug 2018 16:27:00 -0700

> enough as a technical topic, to warrant the redundancy I usually argue

What would you suggest?

Might this be better in "Experimental Considerations" instead of a "Privacy
Considerations" section? (Or to your below comment, in both places?)

>    The address of the initiating SMTP server, from which the message is

Will do.

> So MAY is probably the right choice.

As a receiver of reports, this IP is crucial information, because otherwise
the message source is badly obfuscated by intermediary handling. This in
turn becomes deeply confusing to a domain owner trying to effectively *do
something* with the reports they receive. The feedback loop here is
critical, and is incomplete without the IP.

However, not every entity that ARC Seals has access to this information
(for instance, Mailman uses LMTP and has no direct access to the IP of the
incoming SMTP connection), which is why it is SHOULD. The intent is "must
do this, unless you don't have the ability to or have other good reason."

---

From: Seth Blank <[email-masked]>
Date: Fri, 3 Aug 2018 19:23:04 -0700

As stated previously, I've made all stated changes, with the exception of
the below, for further discussion:

On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker <[email-masked]> wrote:

> with a figure, that shows the role of individual header fields and sets of
> them.
>

This is a good suggestion, but form is unclear. Any guidance from the
working group would be appreciated.

> Arguably, including it/them does NOT alter integrity validation. i suspect
> /ever/.  At the least, be explicit about /what/ integrity is being maintain.
>
> That is, the dkim signature provides a specific kind of integrity.  If it
> validates, that integrity is proved.  If it doesn't, it isn't. covering it
> by ARC doesn't affect either outcome.
>

This feels more like guidance than a requirement for interoperability.
Should it be moved into ARC-USAGE, or further clarified the way suggested?

> and/or operation concerns, benefits, etc. that justify the choice.

I think this is OK for an Experimental draft, especially with the callout
in 11.3.2. For standards track clarification will be essential.

> that the initial algorithm is provided to ensure basic, initial

Understood. Earlier consensus was that this is fine for the experiment (as
algorithm rotation is irrelevant if the experiment fails), and that
requirements for rotation would be part of a final standards track document.

Should these INFORMATIONAL items just be ripped out in the meantime?