Subject: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Wed, 10 Jul 2013 14:02:15 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-appsawg-rfc5451bis-09: Discuss

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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

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