Message Header Field for Indicating Message Authentication Status
draft-kucherawy-sender-auth-header-20

[Ballot discuss]
There are three issues in the DNS-DIR review by Peter Koch which I would like to be addressed before I can support the approval of this document.

1. The draft has issues with terminology, when it again uses 'domain' as a synonym for an organization - even though it goes the laudable approach of re-introducing the term ADMD (which reminds me of X.400, again).

1.2 says:

  This document makes several references to the "trust boundary" of an
  administrative mail domain (ADMD).  Given the diversity among
  existing mail environments, a precise definition of this term isn't
  possible.

Fine, although the relation to X.400 ADMDs might be worth noting to appreciate the historical parallels.  The problem I see is that later in the document the term isn't used consistently, but instead "domain" again appears as an acting entity, as in [2.4.3] "none:  No policy records were published by the sender's domain".

There is a fundamental and reoccuring disagreement about the nature of "a domain" between the DNS and the Mail community, which is fine as long as each group is having internal conversation.  At the overlap areas we have this issue over and over again and I'd really appreciate if that issue would be wider acknowledged and addressed. This isn't only about wording, but also about implications of hierarchy, administrative boundaries, setting "domain wide" defaults and so on.

That said, introducing "ADMD" seems to be a good way forward, if it's used consistentnly and if the distinctions between an ADMD and a (DNS) domain are dealt with properly.

2. More to the protocol level,  the references to DNS error conditions in sections 2.4.3 and 2.4.4 as well as 3 need a bit more thought.

2.4.4 defines the "iprev" method of "authentication" (which reminds me of our, dnsop's, reverse mapping draft under consideration). I can't tell the difference between

  softfail:  The reverse DNS evaluation failed.  In particular, one or
      both of the "reverse" and forward lookups returned no data (i.e. a
      DNS reply code of NODATA).

and

  permerror:  The reverse DNS evaluation could not be completed due to
      some error which is unrecoverable (e.g. a DNS reply code of NODATA
      or NXDOMAIN).  A later attempt is unlikely to produce a final
      result.

First, there is no real reply code of NODATA (the description is usually
NOERROR/NODATA, meaning NOERROR and empty answer section), but it's unclear to me what the author really wants to achieve here.

3. The description of the "iprev" method in section 3 defers details to RFC 4408, which is an experimental RFC, while the draft under consideration aims at Proposed.

4. Also, there's the conceptual/terminology issue again:

  A successful test using this algorithm constitutes a result of "pass"
  since the domain in which the client's PTR claims it belongs has
  confirmed that claim.  A failure to match constitutes a "hardfail".

It isn't that the match acknowledges the membership in some kind of administrative boundary; it's just a consistency check of some limited value.  The whole discussion should take into account the long debate that has taken place in DNSOP regarding the draft-ietf-dnsop-reverse-mapping-considerations draft.  This is currently expired, but will be revived and WGLCed "soon".

[Ballot comment]
Some places that need minor clarifications:

Section 2.4.2, "pass" bullet: "author domain signature" probably
should be "author signature" (the term used in other bullets here,
and in ADSP draft iself).

Section 1: "...are the published e-mail authentication methods in
common use" should probably be phrased something like "domain-level
e-mail authentication methods (as opposed to user-level authentication
mechanisms such as S/MIME and OpenPGP)"

Section 1.5.2: "...a message which validates is indeed entirely
authentic" I think in this context "entirely authentic" could be
misleading; if the signature validates, the signed parts of the
message (the signature doesn't cover everything) haven't been modified
after signing. Whether e.g. the value of the "From" field is entirely
authentic depends on the signing practices (and for e.g. signatures
added by mailing list exploders, that may vary). I'd suggest rephrasing
this to something like "...a message which validates has not been
modified after it was signed", or something like that.

[Ballot comment]
In the Gen-ART Review by Suresh Krishnan, he said that one thing was
  unclear.  He wanted to know how the MUA would convey the results to
  the user.  For example, using the case C.5 from the appendix, what
  would the user actually see (Success indication, Failure indication,
  or something else)?  Is this field used more as input for filters
  rather than communicating authentication information to the user?
  How is the authenticity of the sender established?

IANA Last Call comments:

ACTION 1:

Upon approval of this document, the IANA will make the following
assignments in the "Permanent Message Header Field Names" registry at
http://www.iana.org/assignments/message-headers/perm-headers.html

Header Field Name + Protocol Status Reference
Authentication-Results + mail + + [RFC-kucherawy-sender-auth-header-17]


ACTION 2:

Upon approval of this document, the IANA will create the
following registry at http://www.iana.org/assignments/TBD

Registry Name: Email Authentication Method Name Registry
Registration Procedures: IETF Review

*NOTE: because this is an IETF Review registry, the value
"dkim-adsp" will not be registered until the documentt that
defines it is approved.

Initial contents of this registry will be:

+------------+----------+--------+----------------+--------------------+


| Method | Reference | ptype | property | value |


+------------+----------+--------+----------------+--------------------+


| auth | RFC4954 | smtp | auth | AUTH parameter of |



| | | | | the SMTP MAIL |
| | | | | command |


+------------+----------+--------+----------------+--------------------+


| dkim | RFC4871 | header | d | value of |



| | | | | signature "d" tag |



| | | +----------------+--------------------+



| | | | i | value of |



| | | | | signature "i" tag |


+------------+----------+--------+----------------+--------------------+


| domainkeys | RFC4870 | header | from | value of From |



| | | | | header field |
| | | | | w/comments removed |



| | | +----------------+--------------------+



| | | | sender | value of Sender |



| | | | | header field |
| | | | | w/comments removed |


+------------+----------+--------+----------------+--------------------+


| iprev | [RFC-kucherawy-sender-auth-header-17] | policy | iprev | client IP

address |


| | | | | |


+------------+----------+--------+----------------+--------------------+


| senderid | RFC4406 | header | name of header | value of header |



| | | | field used by | field used by PRA |
| | | | PRA | w/comments removed |


+------------+----------+--------+----------------+--------------------+


| spf | RFC4408 | smtp | mailfrom | envelope sender |



| | +--------+----------------+--------------------+



| | | smtp | helo | HELO/EHLO value |


+------------+----------+--------+----------------+--------------------+


ACTION 3:

Upon approval of this document, the IANA will create the
following registry at http://www.iana.org/assignments/TBD

Registry Name: Email Authentication Result Name Registry
Registration Procedures: IETF Review

Initial contents of this sub-registry will be:
+-----------+----------+----------------+------------------------------+


| Code | Defined | Auth Method(s) | Meaning |


+-----------+----------+----------------+------------------------------+


| none | [RFC-kucherawy-sender-auth-header-17] | dkim | section 2.4.1 |



| | | domainkeys | |



| | +----------------+------------------------------+



| | | dkim-adsp | section 2.4.2 |



| | +----------------+------------------------------+



| | | spf | section 2.4.3 |
| | | sender-id | |



| | +----------------+------------------------------+



| | | auth | section 2.4.5 |


+-----------+----------+----------------+------------------------------+


| pass | [RFC-kucherawy-sender-auth-header-17] | dkim | section 2.4.1 |



| | | domainkeys | |



| | +----------------+------------------------------+



| | | dkim-adsp | section 2.4.2 |



| | +----------------+------------------------------+



| | | spf | section 2.4.3 |
| | | sender-id | |



| | +----------------+------------------------------+



| | | iprev | section 2.4.4 |



| | +----------------+------------------------------+



| | | auth | section 2.4.5 |


+-----------+----------+----------------+------------------------------+


| fail | [RFC-kucherawy-sender-auth-header-17] | dkim | section 2.4.1 |



| | | domainkeys | |



| | +----------------+------------------------------+



| | | dkim-adsp | section 2.4.2 |



| | +----------------+------------------------------+



| | | auth | section 2.4.5 |


+-----------+----------+----------------+------------------------------+


| policy | [RFC-kucherawy-sender-auth-header-17] | dkim | section 2.4.1 |



| | | domainkeys | |


+-----------+----------+----------------+------------------------------+


| neutral | [RFC-kucherawy-sender-auth-header-17] | dkim | section 2.4.1 |



| | | domainkeys | |



| | +----------------+------------------------------+



| | | spf | section 2.4.3 |
| | | sender-id | |


+-----------+----------+----------------+------------------------------+


| temperror | [RFC-kucherawy-sender-auth-header-17] | dkim | section 2.4.1 |



| | | domainkeys | |



| | +----------------+------------------------------+



| | | dkim-adsp | section 2.4.2 |



| | +----------------+------------------------------+



| | | spf | section 2.4.3 |
| | | sender-id | |



| | +----------------+------------------------------+



| | | iprev | section 2.4.4 |



| | +----------------+------------------------------+



| | | auth | section 2.4.5 |


+-----------+----------+----------------+------------------------------+


| permerror | [RFC-kucherawy-sender-auth-header-17] | dkim | section 2.4.1 |



| | | domainkeys | |



| | +----------------+------------------------------+



| | | dkim-adsp | section 2.4.2 |



| | +----------------+------------------------------+



| | | spf | section 2.4.3 |
| | | sender-id | |



| | +----------------+------------------------------+



| | | iprev | section 2.4.4 |



| | +----------------+------------------------------+



| | | auth | section 2.4.5 |


+-----------+----------+----------------+------------------------------+


| nxdomain | [RFC-kucherawy-sender-auth-header-17] | dkim-adsp | section 2.4.2 |



| | | | |


+-----------+----------+----------------+------------------------------+


| signed | [RFC-kucherawy-sender-auth-header-17] | dkim-adsp | section 2.4.2 |



| | | | |


+-----------+----------+----------------+------------------------------+


| unknown | [RFC-kucherawy-sender-auth-header-17] | dkim-adsp | section 2.4.2 |



| | | | |


+-----------+----------+----------------+------------------------------+


| discard | [RFC-kucherawy-sender-auth-header-17] | dkim-adsp | section 2.4.2 |



| | | | |


+-----------+----------+----------------+------------------------------+


| hardfail | [RFC-kucherawy-sender-auth-header-17] | spf | section 2.4.3 |



| | | sender-id | |



| | +----------------+------------------------------+



| | | iprev | section 2.4.4 |


+-----------+----------+----------------+------------------------------+


| softfail | [RFC-kucherawy-sender-auth-header-17] | spf | section 2.4.3 |



| | | sender-id | |



| | +----------------+------------------------------+



| | | iprev | section 2.4.4 |


+-----------+----------+----------------+------------------------------+


We understand the above to be the only IANA Actions for this document.