Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc5451bis-10

[Ballot comment]
Throughout the document, the term "this header field" and "the header field" is used to refer to the Authentication-Results header field. This isn't very user friendly—I keep wondering if the antecedent has changed. Once it's clear to the reader what the document is about, I think this is less of an issue, but it made starting to read it kind of painful. I think it would be more friendly to say "the authref header field" each time, even though it's an extra word. I realize that this is a fairly minor cognitive load for the reader, but when it comes to even minor cognitive loads, less is more.

In 2.5.7:
  Extension results MUST only be used within ADMDs that have explicitly
  consented to use them.
Wouldn't it be better to say:
  Extension results MUST NOT be used within ADMDs that have not explicitly
  consented to use them.

I suggest this because "MUST only" is not an RFC 2119 key word, but I think you mean the two words together to be normative.  It's understandable either way, so this is a minor nit, but take it for what it's worth.

From section 5:

  For simplicity and maximum security, a border MTA could remove all
  instances of this header field on mail crossing into its trust
  boundary.  However, this may conflict with the desire to access
  authentication results performed by trusted external service
  providers.  It may also invalidate signed messages whose signatures
  cover external instances of this header field.  A more robust border
  MTA could allow a specific list of authenticating MTAs whose
  information is to be admitted, removing all others.

Although this alludes to the problem of breaking DKIM, for example, it doesn't fully address it.  A DKIM message may be signed in a way that can be validated, and yet not come from a trusted external service provider.  If the DKIM signature includes an Authentication-Results header, removing it will break the signature, preventing the MUA from validating it.  This seems like a big loss of functionality, since the end user doesn't have a way of opting out of this breakage.

This could be easily mitigated by changing the name of the header field rather than removing it: change it to Elided-Authentication-Results or something.  Then the MUA can reverse that and calculate the DKIM signature.

I realize that this may be a non-issue in practice.  I haven't seen a DKIM signature that signed an Authentication-Results header, and maybe it just never happens.  But this seems so easy to fix that it ought to be worth the minor effort involved.

[Ballot comment]
Throughout the document, the term "this header field" and "the header field" is used to refer to the Authentication-Results header.  This isn't very user friendly—I keep wondering if the antecedent has changed.  Once it's clear to the reader what the document is about, I think this is less of an issue, but it made starting to read it kind of painful.  I think it would be more friendly to say "the authref header field" each time, even though it's an extra word.  I realize that this is a fairly minor cognitive load for the reader, but when it comes to even minor cognitive loads, less is more.

In 2.5.7:
  Extension results MUST only be used within ADMDs that have explicitly
  consented to use them.
Wouldn't it be better to say:
  Extension results MUST NOT be used within ADMDs that have not explicitly
  consented to use them.

I suggest this because "MUST only" is not an RFC 2119 key word, but I think you mean the two words together to be normative.  It's understandable either way, so this is a minor nit, but take it for what it's worth.

From section 5:

  For simplicity and maximum security, a border MTA could remove all
  instances of this header field on mail crossing into its trust
  boundary.  However, this may conflict with the desire to access
  authentication results performed by trusted external service
  providers.  It may also invalidate signed messages whose signatures
  cover external instances of this header field.  A more robust border
  MTA could allow a specific list of authenticating MTAs whose
  information is to be admitted, removing all others.

Although this alludes to the problem of breaking DKIM, for example, it doesn't fully address it.  A DKIM message may be signed in a way that can be validated, and yet not come from a trusted external service provider.  If the DKIM signature includes an Authentication-Results header, removing it will break the signature, preventing the MUA from validating it.  This seems like a big loss of functionality, since the end user doesn't have a way of opting out of this breakage.

This could be easily mitigated by changing the name of the header field rather than removing it: change it to Elided-Authentication-Results or something.  Then the MUA can reverse that and calculate the DKIM signature.

I realize that this may be a non-issue in practice.  I haven't seen a DKIM signature that signed an Authentication-Results header, and maybe it just never happens.  But this seems so easy to fix that it ought to be worth the minor effort involved.

[Ballot discuss]
Updated since the downgrade to PS. I don't think these will take much to sort out.

2.5.2:

You've reversed the sense of the registry by incorporating from the SPF spec. The definition of the registry entries for the codes coming from SPF would now have to point to SPF, not for the meaning, but for the actual names. That would mean that the registry should now be an authentication method registry with the subregistry (or subentries in the table) being the result codes. Very confusing.

4:

  The set of message properties registered for a given method, upon
  which the reported result is based, can be numerous.  However, the
  ones included in the header field being generated SHOULD NOT include
  any that were not included in the computation of the result.  Doing
  so can confound consumers of the field when the method includes
  multiple evaluation methods.  For example, SPF can base its
  conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom
  domain; including both of those in the Authentication-Results header
  field makes it impossible for the consumer to determine which
  property of the message envelope was actually used.

I don't get this paragraph. Are you saying that if SPF used HELO, I SHOULD NOT indicate that I used MAIL FROM? That seems like the height of absurdity to say. If this is something that needs to be called out, I don't understand why it isn't a MUST NOT. What does this mean?

[Ballot comment]
1:

- I found the first sentence of the introduction very abrupt and distracting from the purpose of the document. The mention of "the first version of this document" in the first sentence is anachronistic IMO. Please make the first sentence indicate something about the overall purpose of the document and *then* fall into the details.

- Editorial:

  o  reverse IP address name validation ("iprev", defined in [RFC5451])

Defined in section 3 of this document, not 5451.

  This specification is not intended to be restricted to domain-based
  authentication, but has proven to be a good starting point for
  implementations.  In order to support the propagation of evaluation
  results, and as various message authentication methods emerge, this
  header field encourages convergence for interfacing verifiers to
  filters and MUAs.

I have read those two sentences multiple times and I still have no idea what they're saying.

1.1:

  In particular, the mere presence of this header field SHOULD NOT be
  construed as meaning that its data is valid...

I'm not sure why that changed to a 2119 "SHOULD NOT", but the passive voice and the word "construed" makes it unclear to me what the requirement being stated here is.

1.3:

The new information in 1.3 seems incorrect. Certainly an MUA always looks at an already-delivered email message. The old 1.3 made it clear that this wasn't intended for an embedded message/rfc822 construct, but I always took that to be because it was outside of the trust boundary between the MDA and the MUA. But for messages that are delivered to a mail spool that an MUA reads and displays to the user, it is perfectly appropriate to look in the top-level of that message for the Authentication-Results. That does depend on the MDA and MUA being on the same side of the trust boundary, but other than that there is not a problem. Please explain this change.

1.5.2:

  By contrast, DKIM is agnostic as to the routing
  of a message but uses cryptographic signatures to authenticate agents
  claim (some) responsibility for the message (which implies
  authorization)...
 
That doesn't parse.

2.2:

- Why did you make two separate "-version" elements? The original seemed fine.

- In the comment to pvalue: I think having 2119 MUST language in a comment to ABNF is crazy (being in 5451 notwithstanding). This requirement should be pulled out into the main text below the ABNF.

- The use of the word "amendment" in this section is undefined, and IMO unhelpful.

- Some 2119 nonsense:

  The "ptype" and "property" values used by each authentication method
  MUST be defined in the specification for that method (or its
  amendments).
 
Not only is this a change from 5451, I'm not clear on whom this requirement rests. There is plenty of text in 2.5.6 and 2.5.7 about this. I say strike it from here.

  Where an SMTP command name is being reported as a "property", the
  MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO
  command MUST be represented by "rcptto".  All other SMTP commands
  MUST be represented unchanged.

The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I MUST use it unchanged? Again, who do these requirements apply to?

2.5.1:

I'm not sure why the second paragraph was moved up from below. It makes more sense below, to me.

2.5.6:

  Method identifiers MUST be registered...
  ...such identifiers SHOULD reflect the name of the method...
 
Why MUST? Why SHOULD?

4:

  An MTA compliant with this specification MUST add this header field
  (after performing one or more message authentication tests) to
  indicate which MTA or ADMD performed the test, which test got applied
  and what the result was.  If an MTA applies more than one such test,
  it MUST add this header field either once per test, or once
  indicating all of the results.  An MTA MUST NOT add a result to an
  existing header field.
 
I find this set of requirements weird and unnecessary. The first sentence basically says, "If you implement this document, you MUST implement this document", which is just goofy. The rest says that an MTA MUST NOT add to an existing field, but that seems completely implementation dependent: I might pass partial fields along within an ADMD with trusted MTAs and do exactly that. What I think this is saying is something along the lines of the requirement to remove old ones, but then it's redundant. I don't get this 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.  Further measures may be necessary in some environments.
  Some possible solutions are enumerated in Section 8.1.  This document
  does not mandate any specific solution to this issue as each
  environment has its own facilities and limitations.

The added 2119 in this paragraph doesn't help anyone. There is already a requirement in section 5, and some discussion in 8.1, about what to do and what is required. 2119 keywords with forward pointers to the actual requirements are not helpful. s/MUST take/will. s/REQUIRED//.

[Ballot comment]

- note to RFC editor in the abstract I guess needs changing
now that this is going for PS

- intro: Are ADSP and VBR really in common use?

- 1.6: you say valid use "requires removing" this when the
message first arrives in the ADMD. I think that'd be better
as a "MUST remove" but is clear enough. (Section 5 has a MUST
btw, though also allows for not removing messages you
get *directly* from a "trusted" peer. Is "directly" there
really verifiable in general?)

- 1.7: I guess this is changed by the new PS target.

- 2.3: You say MUAs SHOULD use the authserv-id field to
determine whether to use or ignore the header field. That's
unchanged since 5451 but I wonder if it'd be better to say that
MUAs need to have a whitelist or similar of values that are ok
for this? What's actually done here? (This isn't a discuss since
its the same in 5451.)

- 2.4 and 2.5.7: I think I agree that adding these means that
cycling at PS is correct.

- section 4, 2nd last para: has a new SHOULD NOT that seems
sensible - but I wondered why this was a SHOULD NOT and not a
MUST NOT? I can't think of a case where an AR is better
containing stuff that the MUA can't see. If there are such
cases, maybe mention one. Or maybe I've misinterpreted the
text? (It is a bit hard to get.)

- section 7: Thanks!

[Ballot comment]
I hate to slow down progression of this to IS, but I do agree with Pete's assertion that this probably needs to recycle based on the number of changes.*  (I'll note Barry's already said he's going to make it cycle so no action but thought I should be on record)

How does this draft seemingly get away with not normatively referencing the authentication methods?  On the one hand, I can see the argument that this protocol merely copies information from another protocol to a field and then sends it on its way back to the originator.  On the other hand, doesn't the creator of the report need to understand the various authentication mechanisms to know what result to send back?  And please don't get me wrong, I don't want to hold publishing this up based on this comment - I'm just curious.

*  the diff tool worked nicely here comparing the original rfc and the bis.

[Ballot comment]
Because of the changes being made in the document, I'm changing the target status to Proposed Standard, and it's likely to be presented in six months or so for upgrade to Internet Standard.

[Ballot comment]
I am sympathetic to Pete's DISCUSS on advancing to full standard while making incompatible changes, but I'll let you folks hash that out - it wouldn't affect my ballot position either way.

I found this specification clear and especially appreciated the context in sections like Operational Guidance.

I had some non-blocking comments that I'd ask you to consider along with other comments you might receive.

In 1.1.  Purpose

  In particular, the mere presence of this header field SHOULD NOT be
  construed as meaning that its data is valid, but, rather, that it is
  reporting assertions made by one or more authentication schemes
  applied somewhere upstream. 

This doesn't look like a 2119 SHOULD NOT to me ... are you saying something like "the mere presence of this header field doesn't mean that its data is valid"?

In 1.5.2.  Security

  By contrast, DKIM is agnostic as to the routing
  of a message but uses cryptographic signatures to authenticate agents
  claim (some) responsibility for the message (which implies
  authorization) and ensures that the listed portions of the message
  were not modified in transit. 

This sentence isn't parsing for me. Missing word, perhaps?

In 2.5.1.  DKIM and DomainKeys

  neutral:  The message was signed but the signature or signatures
      contained syntax errors or were not otherwise able to be
      processed.  This result SHOULD also be used for other failures not
      covered elsewhere in this list.

I don't think this is an RFC 2119 SHOULD, but my larger point is, if you encounter a failure that's not covered in this list, what other choice is there? (Return no result? return the wrong result?)

In 6.2.  Email Authentication Method Name Registry

  Each method must register a name, the specification that defines it,
  a version number associated with the method being registered
  (preferably starting at "1"),

this "preferably" is Mostly Harmless, but I'd think if the intent was to avoiding confusing the reader, you'd be better off mandating that. "Preferably" seems to say "you could *probably* trust that version 5 isn't the first version, but you can't know that for certain".

A couple of paragraphs down,

  IANA is also requested to add a "version" field to all existing
  registry entries.  All current methods are to be recorded as version
  "1".

seems to mandate starting at "1" for existing methods, so I'm confused why new methods might not begin with version '1'.

[Ballot discuss]
I am quite uncomfortable with this document going to Internet Standard and not recycling at Proposed Standard. This document makes several significant non-backwards-compatible changes, which is not appropriate for a document advancing in grade. My ballot would be significantly different if this were going for PS. (Indeed, some of these DISCUSS points might go away, but some of the COMMENTs might become DISCUSS points because they are things that are in 5451.) For purposes of advancing to IS:

1.3:

The new information in 1.3 seems incorrect. Certainly an MUA always looks at an already-delivered email message. The old 1.3 made it clear that this wasn't intended for an embedded message/rfc822 construct, but I always took that to be because it was outside of the trust boundary between the MDA and the MUA. But for messages that are delivered to a mail spool that an MUA reads and displays to the user, it is perfectly appropriate to look in the top-level of that message for the Authentication-Results. That does depend on the MDA and MUA being on the same side of the trust boundary, but other than that there is not a problem. Please explain this change. (Note: If this document were recycling at Proposed, this would be a comment, but moving to full Internet Standard, I want to understand the change before moving ahead.)

2.2:

- You are expanding authserv-id to allow quoted-string and disallowing "?", "=", and "/" outside of quotes. This seems like a big change from 5451.

- You are limiting method, result, and property to having nothing but LDH in them. Those are significant changes from 5451.

- In the comment to pvalue: I think having 2119 MUST language in a comment to ABNF is crazy (being in 5451 notwithstanding). This requirement should be pulled out into the main text below the ABNF.

2.5.2:

You've reversed the sense of the registry by incorporating from the SPF spec. The definition of the registry entries for the codes coming from SPF would now have to point to SPF, not for the meaning, but for the actual names. That would mean that the registry should now be an authentication method registry with the subregistry (or subentries in the table) being the result codes. Very confusing.

4:

  The set of message properties registered for a given method, upon
  which the reported result is based, can be numerous.  However, the
  ones included in the header field being generated SHOULD NOT include
  any that were not included in the computation of the result.  Doing
  so can confound consumers of the field when the method includes
  multiple evaluation methods.  For example, SPF can base its
  conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom
  domain; including both of those in the Authentication-Results header
  field makes it impossible for the consumer to determine which
  property of the message envelope was actually used.

I don't get this paragraph. Are you saying that if SPF used HELO, I SHOULD NOT indicate that I used MAIL FROM? That seems like the height of absurdity to say. If this is something that needs to be called out, I don't understand why it isn't a MUST NOT. What does this mean?

[Ballot comment]
1:

- Please repeat the Abstract as the first paragraph of the intro. Some folks don't read abstracts.

- Editorial:

  o  reverse IP address name validation ("iprev", defined in [RFC5451])

Defined in section 3 of this document, not 5451.

  This specification is not intended to be restricted to domain-based
  authentication, but has proven to be a good starting point for
  implementations.  In order to support the propagation of evaluation
  results, and as various message authentication methods emerge, this
  header field encourages convergence for interfacing verifiers to
  filters and MUAs.

I have read those two sentences multiple times and I still have no idea what they're saying.

1.1:

  In particular, the mere presence of this header field SHOULD NOT be
  construed as meaning that its data is valid...

I'm not sure why that changed to a 2119 "SHOULD NOT", but the passive voice and the word "construed" makes it unclear to me what the requirement being stated here is.

1.5.2:

  By contrast, DKIM is agnostic as to the routing
  of a message but uses cryptographic signatures to authenticate agents
  claim (some) responsibility for the message (which implies
  authorization)...
 
That doesn't parse and is a change from 5451.

2.2:

- Why did you make two separate "-version" elements? The original seemed fine.

- You introduce "mailfrom" and "rcptto". Are those already in use? Is there a reason you simply didn't use the command names from 5321 ("mail" and "rcpt")?

- The use of the word "amendment" in this section is undefined, and IMO unhelpful.

- Some 2119 nonsense:

  The "ptype" and "property" values used by each authentication method
  MUST be defined in the specification for that method (or its
  amendments).
 
Not only is this a change from 5451, I'm not clear on whom this requirement rests. There is plenty of text in 2.5.6 and 2.5.7 about this. I say strike it from here.

  Where an SMTP command name is being reported as a "property", the
  MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO
  command MUST be represented by "rcptto".  All other SMTP commands
  MUST be represented unchanged.

The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I MUST use it unchanged? Again, who do these requirements apply to?

2.5.1:

I'm not sure why the second paragraph was moved up from below. It makes more sense below, to me.

2.5.6:

  Method identifiers MUST be registered...
  ...such identifiers SHOULD reflect the name of the method...
 
Why MUST? Why SHOULD?

4:

  An MTA compliant with this specification MUST add this header field
  (after performing one or more message authentication tests) to
  indicate which MTA or ADMD performed the test, which test got applied
  and what the result was.  If an MTA applies more than one such test,
  it MUST add this header field either once per test, or once
  indicating all of the results.  An MTA MUST NOT add a result to an
  existing header field.
 
This appeared in 5451, so if this document does go for IS, this comment ought to be ignored. But if it recycles at PS: I find this set of requirements weird and unnecessary. The first sentence basically says, "If you implement this document, you MUST implement this document", which is just goofy. The rest says that an MTA MUST NOT add to an existing field, but that seems completely implementation dependent: I might pass partial fields along within an ADMD with trusted MTAs and do exactly that. What I think this is saying is something along the lines of the requirement to remove old ones, but then it's redundant. I don't get this 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.  Further measures may be necessary in some environments.
  Some possible solutions are enumerated in Section 8.1.  This document
  does not mandate any specific solution to this issue as each
  environment has its own facilities and limitations.

The added 2119 in this paragraph doesn't help anyone. There is already a requirement in section 5, and some discussion in 8.1, about what to do and what is required. 2119 keywords with forward pointers to the actual requirements are not helpful.

[Ballot discuss]
This discuss is initially for my colleagues on the IESG.

This update to RFC5451 introduces text containing what are almost certainly the trade marked names of a number of products. This does not seem to be called out in the text, which may be a problem for the trade mark owners.

My question (to the IESG) is whether this is something that we need to worry about, or something that we just leave for the RFC Editor to deal with.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-rfc5451bis-07. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible.

We understand that there are three actions to be completed upon approval of this document.

First, in the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers/message-headers.xml

the entry for Authentication-Results is currently registered as follows:

Header Field Name: Authentication-Results
Template:
Protocol: mail
Status: Standard
Reference: [RFC5451]

Upon approval of this document, the reference will be changed to [ RFC-to-be ] as follows:

Header Field Name: Authentication-Results
Template:
Protocol: mail
Status: Standard
Reference: [ RFC-to-be ]

Second, in the Email Authentication Methods subregistry of the Email Authentication Parameters registry located at:

http://www.iana.org/assignments/email-auth/email-auth.xml

the following changes will be made:

- the registration procedure will change from the current "IETF Review" to "Expert Review" as defined by RFC5226
- a new field will be added to the registry for all new and existing registry entries called "Version"
- for any existing registry entry, the new value for "Version" will be set to "1"
- for any existing registry entry whose reference is RFC5451, the reference will be changed to [ RFC-to-be ]

Third, in the Email Authentication Result Names subregistry of the Email Authentication Parameters registry located at:

http://www.iana.org/assignments/email-auth/email-auth.xml

the following changes will be made:

- the registration procedure will change from the current "IETF Review" to "Expert Review" as defined by RFC5226
- for any existing registry entry whose reference is RFC5451, the reference will be changed to [ RFC-to-be ]

We understand that these three actions are the only ones required 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 only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Message Header Field for Indicating Message Authentication Status) to Internet Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Message Header Field for Indicating Message Authentication Status'
  as Internet Standard

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 2013-06-27. 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


  This document specifies a header field for use with electronic mail
  messages to indicate the results of message authentication efforts.
  Any receiver-side software, such as mail filters or Mail User Agents
  (MUAs), can use this header field to relay that information in a
  convenient and meaningful way to users, or make sorting and filtering
  decisions.

  This document is a candidate for Internet Standard status.  [RFC
  Editor: Please delete this notation, as I imagine it will be
  indicated some other way.]




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/ballot/

Reviewers should particularly note the "downref" information in
Section 7.1 of the document.

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