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

Cool to see the Implementation Status section...

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.

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'.

- 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!

I missed the note that section 7 is to be deleted.

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.