Subject: [apps-discuss] Comments on draft-kucherawy-rfc5451bis-01

From: SM <[email-masked]>
Date: Sun, 06 Jan 2013 10:07:11 -0800

Hi Murray,

I have some comments on draft-kucherawy-rfc5451bis-01.  The draft is 
well-written.  I commented off-list about the excessive use of RFC 
2119 key words.  Frankly, I don't know what's the right path as it 
can be argued both ways.

I suggest obsoleting RFC 6577 as well and rolling the changes into 
this document.

In Section 1:

   "This document revises that definition based on current use of
    various authentication protocols in use today and incorporates
    errate logged since the publication of the original specification."

There is a type for "errata".  I gather that the changes are only 
those listed in Appendix E and the errata.

   "[DOMAINKEYS] is also referenced here, though it has "Historic" status
    as it is no longer common.  This proposal is not intended to be
    restricted to domain-based authentication, but this has proven to be
    a good starting point for implementations."

I suggest dropping DomainKeys as it's historic.  Implementers can 
reference RFC 5451 if they need the information.

   "Although [SPF] defined a header field called Received-SPF and
    [DOMAINKEYS] defined one called DomainKey-Status for this purpose,
    those header fields are specific to the conveyance of their
    respective results only and thus are insufficient to satisfy the
    requirements enumerated below."

I suggest aligning the document with the current SPF draft.  You 
don't have to discuss about Received-SPF then.  I favor dropping the 
paragraph to trim the document without losing anything important.

In Section 1.5.2:

   "As examples: [SPF] and [SENDERID] are authorization mechanisms in
    that they express a result that shows whether or not the ADMD that"

I suggest dropping the SENDERID reference.

In Section 2.1:

   "This new header field SHOULD be added at the top of the message as it
    transits MTAs that do authentication checks so some idea of how far
    away the checks were done can be inferred.  It therefore should also
    be treated as a Trace Field as defined in [MAIL], and thus all of the
    related definitions in that document apply."

There is current a discussion about when to use caps. :-)  FWIW, 
Section 3.1 of draft-levine-trace-header-registry-01 provides a 
reason for Trace fields.

 From Section 4.1 of your document:

   "As stated in Section 2.1, this header field SHOULD be treated as
    though it were a trace header field as defined in Section 3.6.7 of
    [MAIL], and hence MUST NOT be reordered and MUST be prepended to the
    message, so that there is generally some indication upon delivery of
    where in the chain of handling MTAs the message authentication was
    done."

You have a "should" in Section 2.1 and a "SHOULD" in Section 4.1 for 
the trace header field argument.  You have a "SHOULD be added at the 
top of the message" in Section 2.1 and a "MUST NOT be reordered and 
MUST be prepended" in Section 4.1.  This causes inconsistencies.  I 
am not aware of this causing any problems.  I suggest (in Section 2.1):

   The header field is added to the top of the message as it transits MTAs that
   do authentication checks so some idea of how far away the checks were
   done can be inferred (See Section 4.1).  It is considered as a Trace
   Field as defined in  Section 3.6.7 of [MAIL], and thus all of the
   related definitions in that document apply.

I would write the Section 4.1 part as follows:

   As stated in Section 2.1, this header field is considered as a 
trace header field
   and hence MUST NOT be reordered and MUST be prepended to the 
message, so that
   there is generally some indication upon delivery of where in the 
chain of handling
   MTAs the message authentication was done."

Section 2.1:

  "The header field MAY appear more than once in a single message, or
   more than one result MAY be represented in a single header field, or
   a combination of these MAY be applied."

I read the definition of "MAY" in RFC 2119.  The "MAY" does not add 
any value here.  I would use lower case or have the text as:

  The header field can appear more than once in a single message, or
   more than one result MAY be represented in a single header field, or
   a combination of these can be applied.

In Section 2.3:

   "MUAs or downstream filters SHOULD use this identifier to determine
    whether or not the data contained in an Authentication-Results header
    field ought to be used or ignored."

I don't see a good reason for a "SHOULD".  I would move this text to 
Section 4.1 as it discusses about "Interpretation".

   "The uniqueness of the identifier MUST be guaranteed by the
    ADMD that generates it and MUST pertain to exactly that one ADMD."

   "For simplicity and scalability, the authentication service identifier
    SHOULD be a common token used throughout the ADMD, such as the DNS
    domain name used by or within that ADMD."

   "For tracing and debugging purposes, the authentication identifier MAY
    instead be the hostname of the MTA performing the authentication
    check whose result is being reported."

You have a "MUST" for uniqueness and one for restricting the 
identifier to the ADMD.  You then have a SHOULD for a unique 
identifier for the ADMD.  You then have a "MAY" with an 
explanation.  I'd say keep it simple.

    The authentication service identifier field provides a unique
    identifier that refers to the authenticating service within a
    given ADMD.  It is intended to be machine-readable and not
    necessarily meaningful to users.  The uniqueness of the identifier
    MUST be guaranteed by the ADMD that generates it and MUST pertain
    to exactly that one ADMD.  For simplicity and scalability, the
    authentication service identifier would be a common token used
    throughout the ADMD, such as the DNS domain name used by or within
    that ADMD.

    For tracing and debugging purposes, the authentication identifier may
    instead be the hostname of the MTA performing the authentication
    check whose result is being reported. (remainder of that paragraph)

Section 2.3

   'Examples of valid authentication identifiers are "example.com",
    "mail.example.org", "ms1.newyork.example.com", and "example-auth".'

"example-auth" cannot be guaranteed to be unique.  It violates the "MUST".

For Section 2.4.1, see my previous comment about DomainKeys.  For 
Section 2.4.2, see my previous comment about Sender-ID.

In Section 2.4.5:

   "Additional result codes (extension results) might be defined in the
    future by later revisions or extensions to this specification.
    Result codes MUST be registered with the Internet Assigned Numbers
    Authority (IANA) and preferably published in an RFC.  See Section 6
    for further details."

   "Extension results MUST only be used within ADMDs that have explicitly
    consented to use them.  These results and the parameters associated
    with them are not formally documented."

The above is not clear to me.  Am I allowed to extend this 
specification without IETF review?  I misunderstood this part at 
first as I missed the "x-" that was in this section before.  I'll 
comment below.

You have already defined the initial methods (Section 2.5.1) in RFC 
5451.  I suggest moving the table in Section 6.2 to Section 2.5.1 and 
adjust the text in that section accordingly.

In Section 2.5.2:

   "Additional authentication method identifiers (extension methods) may
    be defined in the future by later revisions or extensions to this
    specification.  Method identifiers MUST be registered with the
    Internet Assigned Numbers Authority (IANA) and, preferably, published
    in an RFC."

   "Experimental method identifiers MUST only be used within ADMDs that
    have explicitly consented to use them.  These method identifiers and
    the parameters associated with them are not documented in RFCs."

Section 2.5.2 previously used "x-" for experimental stuff.  This 
version of the specification removes that.  However, it keeps the 
previous logic where there are registered and experimental 
methods.  It's easier to tell people to register what they are using 
and specifying the requirements for that (First Come First Serve, for 
example).  You can then get rid of the "Experimental method 
identifiers MUST only be used within ADMDs" requirement.  I suggest 
rewriting the requirements where methods which are not supported are 
ignored.  There is already text for that in Section 4.1.

In Section 4:

   'Each "method" MUST refer to an authentication method declared in the
    IANA registry, or an extension method as described in Section 2.5.2,
    and each "result" MUST refer to a result code declared in the IANA
    registry, or an extension result code as defined in Section 2.4.5.
    See Section 6 for further information about the registered methods
    and result codes.'

I don't see any reason for the above paragraph.

   "An MTA adding this header field MUST take steps to identify it as
    legitimate to the MUAs or downstream filters that will ultimately
    consume its content.  One REQUIRED process to do so is described in
    Section 5."

There is only one REQUIRED process.  The process is not about "adding 
the header".  I suggest removing this paragraph.

   "Moreover, this header field SHOULD be inserted above any other trace
    header fields such MTAs might prepend."

There is a "MUST prepend" in Section 4.1 while the above has a "SHOULD".

  "An MTA SHOULD remove any instance of this header field bearing a
   version (express or implied) that it does not support."

It's easier to ignore such instances instead of removing them.  Would 
letting such headers through cause a problem?

   "However, an MTA MUST remove such a header field if the [SMTP]
    connection relaying the message is not from a trusted internal MTA."

I don't understand this requirement.  It's easier to have simple 
requirements for when to remove (as mentioned in the first two 
paragraphs of Section 5) instead of requirements in several places 
which are applicable under different conditions.

I suggest keeping the IANA Considerations for instructions to 
IANA.  For Section 6:

   The entry in the IANA Permanent Message Header Field Registry is updated
   to reference this document.

   The following is the registration template:

      Header field name: Authentication-Results
      Applicable protocol: mail ([MAIL])
      Status: Standard
      Author/Change controller: IETF
      Specification document(s): [this memo]
      Related information:
        Requesting review of any proposed changes and additions to
        this field is recommended.

Section 6.1 can then be dropped.

   The following entry in the Email Authentication Method Name 
Registry is update
   to reference this document:

    +------------+----------+--------+-------------+--------------------+
    |    iprev   | [this    | policy | iprev       | client IP address  |
    |            |  RFC]    |        |             |                    |
    +------------+----------+--------+-------------+--------------------+

   The following entries in the Email Authentication Result Name Registry are
   updated to reference this document:

    +-----------+----------+-------------+------------------------------+
    |   Code    | Defined  | Auth        | Meaning                      |
    |           |          | Method(s)   |                              |
    +-----------+----------+-------------+------------------------------+
    | none      | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | pass      | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | fail      | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
     |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | policy    | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    +-----------+----------+-------------+------------------------------+
    | neutral   | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    +-----------+----------+-------------+------------------------------+
    | temperror | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | permerror | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | softfail  | [this    | spf         | section 2.4.2                |
    |           |  RFC]    | sender-id   |                              |
    +-----------+----------+-------------+------------------------------+

As a FYI, RFC 6577 amended the Email Authentication Methods and Email 
Authentication Result Names registries.  The registries use "Expert 
Review".  "Experts are expected to apply applicable documented review 
or vetting procedures, or in the absence of documented criteria, 
follow generally accepted norms".  The guidance in the document is:

   "The Designated Expert has discretion to request that a publication
    be referenced if a clear, concise definition of the authentication
    method cannot be provided such that interoperability is assured.
    Registrations should otherwise be permitted."

"The evaluation process is not intended to be secretive or bestow 
unquestioned power on the expert".  I suggest:

  (i)   Identifying a mailing list for the registration requests and 
discussions.

  (ii)  Deciding whether First Come First Served with some minimal checks
        is adequate as the lowest bar.

  (iii) Defining registration templates

  (iv)  Documenting how to deprecate a registration.

 From Section 7:

   "Another would be a means to interrogate the MTA that added the
    header field to see if it is actually providing any message
    authentication services and saw the message in question, but this
    isn't especially palatable given the work required to craft and
    implement such a scheme.

I don't consider the above as feasible.

   "Yet another might be a method to interrogate the internal MTAs
    that apparently handled the message (based on Received: header
    fields) to determine whether any of them conform to Section 5 of
    this memo.  This, too, has potentially high barriers to entry.

Ok, you thought about it. :-)

   "Extensions to [IMAP], [SMTP], and [POP3] could be defined to
    allow an MUA or filtering agent to acquire the "authserv-id" in
    use within an ADMD, thus allowing it to identify which
    Authentication-Results header fields it can trust.

I suggest removing this paragraph as it does not add much value.

I suggest making AR-ORIG informative as I do not need to read it to 
understand this document.  EMAIL-ARCH should reference RFC 5598.

I may have missed some stuff as I wrote the review.  I didn't notice 
any changes that could affect backward compatibility.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Jan 2013 16:55:44 +0100

> reference RFC 5451 if they need the information.

I agree, if at the same times the I-D marks the domainkeys method and
related result names as "deprecated" in IANA registries.

> "example-auth" cannot be guaranteed to be unique.  It violates the

That "example-auth" reinforces that identifiers are only meaningful
within a given ADMD.  They cannot be unique for a generic MUA that
fetches messages from unrelated, possibly non-conforming servers.

Even if all servers are conforming, the technique described in the
first paragraph of Section 5 can only work within a single ADMD.  It
is not interoperable, in the sense that the indication that "the
header field was added within example.com" is an unspecified
implementation detail.  IMHO, 5451bis can be improved by specifying
it.  Otherwise, I'd strike that sentence (The uniqueness of the
identifier MUST be guaranteed by the ADMD that generates it and MUST
pertain to exactly that one ADMD) as it's difficult to make any sense
of it.

Section 2.3 also says:

   Moreover, some implementations have considered appending a
   delimiter such as "/" and following it with useful transport
   tracing data such as the [SMTP] queue ID or a timestamp.

I gather only the first part is to be checked, in that case.

Finally, the "MUST delete" at the beginning of Section 5 can be
softened to "MUST delete or rename", e.g. transforming it into an
harmless but debuggable field like:

   Old-Authentication-Results: unknown.id; ...

> The following entries in the Email Authentication Result Name
> Registry are updated to reference this document:
> 

Let's not forget there's a Status column too.

> follow generally accepted norms".

In that case, the bottom paragraph of Section 2.5.2 could be softened
so as to require ignoring just the resinfo clauses related to unknown
methods, not the whole header field.

>  (i)   Identifying a mailing list for the registration requests and

Is that going to be apps-discuss?