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

From: "Pete Resnick" <[email-masked]>
Date: Mon, 08 Jul 2013 12:24:33 -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:
----------------------------------------------------------------------

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?

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Jul 2013 23:27:01 -0700

On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick <[email-masked]>wrote:

> [...]

The changes you're calling backward compatible are to the best of my
knowledge already implemented.  A few of the ABNF changes fix errors (with
matching errata), while others describe common changes implemented by the
community since RFC5451 was published (i.e., they did what the original
work had meant to say, not what it said).

However, I don't think that argument is going to sway anyone supporting
this DISCUSS that would rather we follow a pure path here, so I'm fine with
downgrading this to a recycle at Proposed Standard, and simply requesting
advancement in-place after six months to a year when we're sure these
changes don't disrupt any of the installed base.  I've talked to my
document shepherd and the sponsoring AD, and they're in agreement.

So, Pete, would you like to re-cast your ballot with that in mind?  I'll
ignore what you have here as DISCUSS until you've done so on the assumption
that this choice solves most of those concerns, and focus on your COMMENT
points instead.  I'll reply separately about that.

Also, Barry: I have a -10 in the hopper to respond to the Gen-ART review.
I'll hold off posting that until Pete and I work through what's left of his
issues, unless you'd like me to do otherwise.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Jul 2013 00:12:19 -0700

Replying now to your COMMENT points:

OK.

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

Fixed.

> I have read those two sentences multiple times and I still have no idea

Looks like some words got cut someplace along the line.  I'll fix it up.
The point is to note that all of the methods authenticate domain names in
one way or another, or even users at domains.  There are other identifiers
that might be the subject of evaluation now or in the future (the client IP
address, perhaps, or something that authenticates something else
entirely).  Implementers shouldn't assume that this work is only useful for
authentication of domain names just because that's all there is right now;
it should be considered for methods that evaluate other identifiers of a
message, envelope, or transport as well.

> requirement being stated here is.

The change here was made because 2119 isn't case-specific, so if "should
not" is really "SHOULD NOT", it should be shown that way.

I'll reword around it.

> That doesn't parse and is a change from 5451.

Grammar fix-up looks easy.  The change from 5451 is the addition of
"(some)", which is just in line with how DKIM is commonly explained.
There's no semantic change.

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

This was suggested in the working group.  The syntax is indeed identical,
but the prose describing the use of each (and the tie to the IANA registry
in one case) is different.  The suggestion was to split them so that their
slightly different uses were more obvious even if the actual syntax is the
same.

> there a reason you simply didn't use the command names from 5321 ("mail"

Yes, they are already in use.  This was polled from among implementers that
use A-R to relay SPF results, which is where this counts.

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

Changed to "update".

> I say strike it from here.

Struck.

> it unchanged? Again, who do these requirements apply to?

The MUST applies to the agent generating this header field and adding it to
a message.  I'll clean up that paragraph.

> I'm not sure why the second paragraph was moved up from below. It makes

One of the reviewers had the opposite advice, namely to define the term
"acceptable to the verifier" before using it.

>    ...such identifiers SHOULD reflect the name of the method...

I think those go back to an old SecDir review.  They don't need to be
2119ese, I think.

> requirement to remove old ones, but then it's redundant. I don't get this

The first part doesn't need the MUST, I agree.  The second part enforces
that the field is trace data within the meaning of RFC5321, so one isn't
supposed to monkey with its content or its order if it's already there.  If
you have more authentication information to add, prepend a new field.

> requirements are not helpful.
This is just another lower-to-upper of 2119 key words that were in the
previous version.  I'll reword around them.

-MSK

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Jul 2013 18:49:40 +0900

No, please don't! There are plenty of folks who read both abstract and 
introduction, and it's really annoying to read the same thing twice.

So please make sure that there is no information in the abstract that 
isn't also in the body text (which starts at the introduction), but 
please don't just copy the abstract into the introduction.

Regards,   Martin.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 09 Jul 2013 10:37:59 -0700

> introduction, and it's really annoying to read the same thing twice.

+10

It's worse than Martin has said.

The job of an Abstract is quite different from the job of the first 
paragraph of an Introduction.

The purpose of an abstract is to market the document to potential 
readers.  It must, therefore, operate as a standalone precis of the 
document.  Hence, an Abstract must summarize the nature of the document. 
  In the case of IETF specifications, this typically means summarizing 
the problem, possibly summarizing the factors affecting solution 
efforts, and give some indication of the solution approach.

The first paragraph of an Introduction can take a variety of 
perspectives, since it is only the first of a number of paragraphs in 
only the first of a number of sections.  Typically, the first paragraph 
sets the stage for the operational environment, or it sets the stage 
form the problems within that environment.  This covers only a small 
part of the scope of an Abstract.

Bad, Pete.  Bad.  Tsk. Tsk.

d/

ps. To make matters a bit confusing, the first paragraph of a /charter/ 
is supposed to operate as an abstract/marketing-blurb for a working 
group, since that paragraph is circulated independent of the rest of the 
charter, as part of the wg announcement.  Unfortunately, that 
requirement is never enforced.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Jul 2013 10:53:36 -0700

Pete's asked me to reply to the DISCUSS points as well to help him change
his ballot based on my responses:

> Internet Standard, I want to understand the change before moving ahead.)

The augmented text is meant to address some of the issues that were raised
since the publication of RFC5451, including the appeal of that document's
approval to the IESG.  There exists an argument that this field should
carry with it enough information for the MUA to repeat the authentication
steps before deciding whether or how to render the message to a user.  For
example, proponents of that argument claim the IP address should be
included in this field so that MUAs can repeat SPF at the time the message
is rendered.

Certainly MUAs will be consuming the content of this field after delivery
to an inbox, but the goal here is not to enable them to do new
authentication work, but rather to apply the results of prior
authentication work.

An A-R field that's part of a message/rfc822 MIME part could bear an
authserv-id that the MUA would normally trust, but it's dicey to believe
that field was subjected to the required scrubbing rules this document
specifies.

Any suggestions to make the above clear?

> in them. Those are significant changes from 5451.

We're recycling at PS primarily for this reason.

OK.

> table) being the result codes. Very confusing.

This was done in the spirit of not copying the content of one RFC into
another.  Unlike DKIM and the others, the list of possible outcomes and
their definitions are enumerated in a different RFC for SPF, so it seemed
like a cleaner solution.  If it turns out the cost of the leaner document
is too high in the way you've described, I can revert.

> don't understand why it isn't a MUST NOT. What does this mean?

SPF can produce a result based on either the HELO or MAIL FROM data
provided as part of the SMTP session.  If one were to generate an A-R field
that says "spf=pass smtp,mailfrom=XXX smtp.helo=YYY", I am unable to tell
which of the two parameters was used to produce the "pass" result.  For an
agent that wants to know that, this limitation is required.  So, "yes" to
your second sentence.  I'm fine with making it a MUST NOT; I think SHOULD
NOT was there for a not-very-good reason in retrospect.

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Tue, 9 Jul 2013 14:18:51 -0500

On 7/9/13 12:37 PM, Dave Crocker wrote:
>>> - Please repeat the Abstract as the first paragraph of the intro.
>>
>> No, please don't!
>

Yeah, yeah. That'll teach me for doing the engineer thing I always 
complain about by suggesting solutions (and, I'll admit, a bad one in 
this case) when I haven't stated what my problem is. I shall rephrase 
(and update my comment to match):

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.

I'll get to the rest of Murray's replies in just a bit.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Jul 2013 12:43:19 -0700

On Tue, Jul 9, 2013 at 12:18 PM, Pete Resnick <[email-masked]>wrote:

> 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.
>
>
>
Easy enough; I can just remove the "original document" reference, because I
don't think it's actually necessary.  The rest falls out nicely after some
minor reshuffling.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 09 Jul 2013 12:51:43 -0700

> purpose of the document and *then* fall into the details.

Oh.  Well, yeah.  That's certainly worth changing.

More generally, we need "The Elements of IETF Specification Style".

d/

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2013 23:15:23 -0000

>More generally, we need "The Elements of IETF Specification Style".

...

6) Omit needless paragraphs.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 09 Jul 2013 18:21:32 -0700

> 6) Omit needless paragraphs.

5) Write normative text that specifies clear, objective criteria and 
clear, objective actions.

This will preclude directives such as 6.

d/

---

From: Ned Freed <[email-masked]>
Date: Tue, 09 Jul 2013 18:38:41 -0700 (PDT)

+10 as well.

> paragraph of an Introduction.

It most certainly is.

> efforts, and give some indication of the solution approach.

This problem is exacerbated to a great degree by the ready availability
of RFCs. Any time the abstract doesn't suffice to describe the document
you can readily access the document itself, so why bother? It's not
like the rest of the document is behind a paywall, as it so often
is for stuff published in academic journals, right?

Except this is sloppy thinking leading to sloppy documents. It's a question of
scale. Not everyone is focused on RFCs like we are. For many if not most
readers RFCs are a small part of the material they consume. And those folks
aren't going to pull the whole document and wade through it, even though it's
easy enough to do. The abstract really does need to stand alone.

This, BTW, is why stuff like "This document obsoletes this other document you
could not care less about" has no business being in an abstract.

> part of the scope of an Abstract.

My advice, from having written a lot of these things, is to not even try to
write the abstract until the document is fully formed. Up to that point you can
simply have something like "this document specifies the foo protocol for
frobbing globules" in there.

> requirement is never enforced.

Good point.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Jul 2013 07:14:47 -0700

On 7/9/2013 6:38 PM, Ned Freed wrote:
>> readers.
...
> of RFCs.
...
> scale. Not everyone is focused on RFCs like we are.

I think this issue is worth pressing a bit further.  (And this is only 
meant to augment Ned's note; I agree strongly with all of his points.)

I classed the issue as 'marketing' because the important role of an 
abstract is to help potential readers to decide whether to become actual 
readers.

In the real world of the web, folks who worry about usability of web 
pages worry quite a bit about key clicks and minimizing them.  Extra key 
clicks lose users.  No single key click seems to cost much, but there's 
a real behavioral barrier.  So while yes, the real document is "only" a 
key-click away, that's actually quite far.

On the average, much of the work in the IETF is executed with other 
IETFers in mind, rather than with non-IETFers in mind.  An abstract is 
meant for someone who is not already likely to read the document.  It 
should be written with a pedagogy targeting that sort of market.

And there's an extra benefit in such writing.  An ability to write a 
good capsule summary of the document tends to require a good 
understanding of what's important about it and that often requires some 
careful thought.

d/

---

From: Pete Resnick <[email-masked]>
Date: Wed, 10 Jul 2013 15:54:57 -0500

Skipping by the ones that we all agree on how to fix.

On 7/9/13 12:53 PM, Murray S. Kucherawy wrote:
> Pete's asked me to reply to the DISCUSS points as well to help him 
> change his ballot based on my responses:
>
> On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     1.3:
>
> The augmented text is meant to address some of the issues that were 
> raised since the publication of RFC5451, including the appeal of that 
> document's approval to the IESG.  There exists an argument that this 
> field should carry with it enough information for the MUA to repeat 
> the authentication steps before deciding whether or how to render the 
> message to a user.  For example, proponents of that argument claim the 
> IP address should be included in this field so that MUAs can repeat 
> SPF at the time the message is rendered.
>
> Certainly MUAs will be consuming the content of this field after 
> delivery to an inbox, but the goal here is not to enable them to do 
> new authentication work, but rather to apply the results of prior 
> authentication work.

Well, why don't you say that? Say that the intention is not to allow the 
consumer of the field to re-create the authentication work, but rather 
to simply signal to the consumer that the work was done by someone they 
trust in the ADMD.

> authserv-id that the MUA would normally trust, but it's dicey to 
> believe that field was subjected to the required scrubbing rules this 
> document specifies.

Right. So that's worth preserving from 5451.

> another.  Unlike DKIM and the others, the list of possible outcomes 
> and their definitions are enumerated in a different RFC for SPF, so it 
> seemed like a cleaner solution.  If it turns out the cost of the 
> leaner document is too high in the way you've described, I can revert.

I am equally OK with either putting the values for SPF back in (because 
it is only coincidental to this spec that the names of the codes are the 
same as the names of the SPF result values, unlike for other protocols) 
or switching the first two columns in the registry. Whichever makes life 
easier.

> provided as part of the SMTP session.  If one were to generate an A-R 
> field that says "spf=pass smtp,mailfrom=XXX smtp.helo=YYY", I am 
> unable to tell which of the two parameters was used to produce the 
> "pass" result.

Can't I conclude from that A-R that the server ran against both MAIL 
FROM and HELO and passed both of them?

> For an agent that wants to know that, this limitation is required.  
> So, "yes" to your second sentence.

My second sentence was meant to be absurd: If I used HELO, saying MAIL 
FROM is not something that I would *ever* consider doing, so there's no 
need to say SHOULD (or MUST) NOT. I can't figure out the case where I 
would report a result for a computation that I did not in fact do. You 
don't need to tell me in the protocol that I shouldn't do that. It's 
like saying, "You MUST NOT put something in the Message-ID field that is 
not the Message-ID." Well, duh. What possible scenario is there in which 
I might mistakenly report a result that I did not in fact compute?

> I'm fine with making it a MUST NOT; I think SHOULD NOT was there for a 
> not-very-good reason in retrospect.

Surely I'm missing something, but given the explanation so far, I say 
strike the whole paragraph.

On 7/9/13 2:12 AM, Murray S. Kucherawy wrote:
> On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> Looks like some words got cut someplace along the line.  I'll fix it 
> up.  The point is to note that all of the methods authenticate domain 
> names in one way or another, or even users at domains.  There are 
> other identifiers that might be the subject of evaluation now or in 
> the future (the client IP address, perhaps, or something that 
> authenticates something else entirely).  Implementers shouldn't assume 
> that this work is only useful for authentication of domain names just 
> because that's all there is right now; it should be considered for 
> methods that evaluate other identifiers of a message, envelope, or 
> transport as well.

Well, that's fine and you should say that. I still don't understand what 
the words, "this header field encourages convergence for interfacing 
verifiers to filters and MUAs" mean.

> This was suggested in the working group.  The syntax is indeed 
> identical, but the prose describing the use of each (and the tie to 
> the IANA registry in one case) is different.  The suggestion was to 
> split them so that their slightly different uses were more obvious 
> even if the actual syntax is the same.

(*Shrug*) OK.

>     - The use of the word "amendment" in this section is undefined,

No, I was being too obscure. The words "and subsequent amendments" (or 
"update") and the like are not useful. For example, you don't know if 
updates to SMTP will result in commands that are similarly two-worded 
like "MAIL FROM" and therefore will need separate registration. I say 
simply strike the "amendment/update" language throughout.

> The MUST applies to the agent generating this header field and adding 
> it to a message.  I'll clean up that paragraph.

Sounds like a definition where the MUSTs aren't necessary.

> One of the reviewers had the opposite advice, namely to define the 
> term "acceptable to the verifier" before using it.

A difference of editorial taste, I suppose. Count me as a reviewer who 
liked it better the old way. Do with that what you will.

>     4:
>
>        If an MTA applies more than one such test,
>     [This] says that an MTA MUST NOT add to an existing
> [This] enforces that the field is trace data within the meaning of 
> RFC5321, so one isn't supposed to monkey with its content or its order 
> if it's already there.  If you have more authentication information to 
> add, prepend a new field.

OK, so I get the MUST NOT. But I don't get the MUST: What else could I 
do but add once per test or one field with everything? What are you 
telling me I MUST NOT do by telling me I MUST do this?

> previous version.  I'll reword around them.

One suggestion here: Don't reword MUST to "needs to" or REQUIRED to 
"necessary". In the cases in this document where the MUSTs are 
unnecessary, make it simply some conjugation of "to be".

pr