[dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-dmarc-rfc7601bis-04: 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-rfc7601bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5317



IMPORTANT
S 7.10.
>      processing of these is outside of the intended scope of this document
>      (see Section 1.3), some early guidance to MUA developers is
>      appropriate here.
>   
>      Since MTAs are unlikely to strip Authentication-Results header fields
>      after mailbox delivery, MUAs are advised in Section 4.1 to ignore

I think you want to be stronger than "are advised to"

COMMENTS
S 1.1.
>      its contents are valid.  Rather, the header field is reporting
>      assertions made by one or more authentication schemes applied
>      somewhere upstream.  For an MUA or downstream filter to treat the
>      assertions as actually valid, there must be an assessment of the
>      trust relationship among such agents, the validating MTA, and the
>      mechanism for conveying the information.

And also a trustworthy path from the validating MTA


S 1.2.
>      Thus, this document defines a "trust boundary" as the delineation
>      between "external" and "internal" entities.  Services that are
>      internal -- within the trust boundary -- are provided by the ADMD's
>      infrastructure for its users.  Those that are external are outside of
>      the authority of the ADMD.  By this definition, hosts that are within
>      a trust boundary are subject to the ADMD's authority and policies,

This seems like a reasonable design, but not the only one. For
instance, Gmail might attach these headers, but I don't think of my
MUA as being subject to its authority and policies.


S 1.5.1.
>   
>   1.5.1.  Key Words
>   
>      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>      document are to be interpreted as described in [KEYWORDS].

I'm probably the 10th person to suggest 8174 boilerplate.


S 1.5.3.
>      agents, assign (some) responsibility for the message (which implies
>      authorization), and ensure that the listed portions of the message
>      were not modified in transit.  Since the signatures are not tied to
>      SMTP connections, they can be added by either the ADMD of origin,
>      intermediate ADMDs (such as a mailing list server), other handling
>      agents, or any combination.

I'm not sure how persuaded I am by this terminology. However,
regardless of that, this claim about SPF seems problematic in the
sense that you could have an intermediate MTA decorate the message
with the incoming IP address (in some unspecified way)  but then have
the terminal MTA do the SPF validation.


S 2.2.
>      combination of these can be applied.
>   
>   2.2.  Formal Definition
>   
>      Formally, the header field is specified as follows using Augmented
>      Backus-Naur Form ([ABNF]):

An example would be kind of helpful here.


S 2.4.
>   
>      This ptype existed in the original specification for this header
>      field, but without a complete description or example of intended use.
>      As a result, it has not seen any practical use to date that matches
>      its intended purpose.  These added details are provided to guide
>      implementers toward proper use.

This text is odd in a bis draft, because "the original" is not 7601 or
7001.


S 5.
>      example.com receiving a message MUST delete or otherwise obscure any
>      instance of this header field bearing an authentication service
>      identifier indicating that the header field was added within
>      example.com prior to adding its own header fields.  This could mean
>      each MTA will have to be equipped with a list of internal MTAs known
>      to be compliant (and hence trustworthy).

It's not "known to be compliant" but rather "known to be trusted by
any MUA within the trust boundary"


S 5.
>      version (express or implied) that it does not support.  However, an
>      MTA MUST remove such a header field if the [SMTP] connection relaying
>      the message is not from a trusted internal MTA.  This means the MTA
>      needs to be able to understand versions of this header field at least
>      as late as the ones understood by the MUAs or other consumers within
>      its ADMD.

Doesn't this have the impact of breaking signatures as you just said
above?


S 7.1.
>   7.1.  Forged Header Fields
>   
>      An MUA or filter that accesses a mailbox whose messages are handled
>      by a non-conformant MTA, and understands Authentication-Results
>      header fields, could potentially make false conclusions based on
>      forged header fields.  A malicious user or agent could forge a header

I think the text here you want is that the MUA understands these
fields, not the non-conformant MTA. So perhaps you can rewrite this?


S 8.2.
>   
>      A message that was delivered by an MTA that conforms to this
>      specification and applied some message authentication:
>   
>           Authentication-Results: example.com;
>                     spf=pass smtp.mailfrom=example.net

Maybe this example would be good to put up front?


S 8.2.
>          to know how to do the work that upstream MTAs do; they only need
>          the results of that work.
>   
>      4.  Evaluations about the quality of a message, from simple token
>          matching (e.g., a list of preferred DNS domains) to cryptanalysis
>          (e.g., public/private key work), do have a cost and thus need to

This is not usually what we would call "cryptanalysis". Perhaps you
mean "cryptographic verification"?