Subject: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00

From: S Moonesamy <[email-masked]>
Date: Fri, 03 May 2013 14:26:14 -0700

Hi APPSAWG,

This message initiates a two weeks WGLC on 
draft-ietf-appsawg-rfc5451bis-00 ("Message Header Field for 
Indicating Message Authentication Status") [1].  Please send your 
comments to the mailing list before the end of Friday May 
17.  Comments saying that you reviewed the draft and you are happy 
for it to be sent for IETF Last Call are also valuable.

Regards,
S. Moonesamy (as document shepherd)

1. http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 06 May 2013 18:29:40 +0200

On Fri 03/May/2013 23:26:14 +0200 S Moonesamy wrote:
> draft-ietf-appsawg-rfc5451bis-00 ("Message Header Field for Indicating
> Message Authentication Status") [1].  Please send your comments to the
> mailing list before the end of Friday May 17.  Comments saying that
> you reviewed the draft and you are happy for it to be sent for IETF
> Last Call are also valuable.

Some comments:

The -00 version still says "Individual submission".  Shouldn't that be
changed to Network Working Group or some such?

1.3. *Processing Scope*

The sentence "It is not meant to address the security of [...]" seems
to refer to the addition of the field only, not its use by a consumer.
 For clarity, I'd s/It/The addition of this field/ or similar wording.
 It may be worth to mention that the field can qualify reported or
attached messages if trusted, and that ARF uses it in its
machine-readable part.

2.2. *Formal Definition*

There is a mismatch "authres-version" != "authserv-version".

2.3. *Authentication Identifier Field*

I tend to associate syntax with production rules, so I'm unable to
make sense of the sentence:

   This is similar in syntax to a fully-qualified domain name.

In the next paragraph, there is a difficult sentence:

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

What is actually required is not the "uniqueness" of the identifier,
but the ability to univocally identify the responsible ADMD using the
identifier.  I'd suggest to rephrase the sentence accordingly.

2.5.2. *SPF and Sender-ID Results*

I propose to delete the list of results:  Since they are already
defined in the relevant RFCs, it is not clear if the I-D means to
update those definitions, redefine them from scratch, or just refer to
the existing definitions.  I'd propose the following instead:

   The values "none", "neutral", "pass", "fail", "softfail",
   "temperror", and "permerror" are the possible results of the
   check_host() function.  One of them can be reported as the
   corresponding method's result, along with the "ptype.property" of
   the argument actually used to obtain it.  In case multiple checks
   gave the same result, multiple propspec can be given for it.

The definition of "policy" has to given in any case.  For a nit, I
think it might be a better example to rewrite the last but one
paragraph as:

   The "policy" result would be returned if, for example, [SPF]
   returned as "pass" result, but the local policy check finds that
   the sender's policy is unacceptable (e.g. terminates with "+all").

6.3. *Email Authentication Result Name Registry*

OLD
   All existing registry entries that reference [AR-ORIG] are to be
   updated to reference this document.
NEW
   All existing registry entries that reference [AR-ORIG] are to be
   updated to reference this document.  Where the meaning refers to
   section 2.4.* it has to be changed to section 2.5.*, due to the
   insertion of a new Section 2.4 in this document.

8.1. *Normative References*

[AR-ORIG] will be obsolete by the time this I-D is published.  How can
it be a normative reference?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 May 2013 13:43:54 -0700

> changed to Network Working Group or some such?

The RFC Editor always changes that to Network Working Group.  It's probably
only there because I copied the XML from some other draft that had it.
Safe to ignore.

> attached messages if trusted, and that ARF uses it in its

Although you're right about the intent of the document, the point of this
section is to indicate that it covers entire messages only, not
encapsulated messages.  It doesn't have anything to do with the consumer.

> There is a mismatch "authres-version" != "authserv-version".

Right; fixed.

>    This is similar in syntax to a fully-qualified domain name.

You're aware of how this works; what would you suggest?  The ABNF is
"value" because it is usually an FQDN, but we also say that it doesn't have
to be.

> identifier.  I'd suggest to rephrase the sentence accordingly.

Are those not synonymous?  From the perspective of a module consuming this
field, it has to be the case that such a module can safely assume that a
field bearing the authserv-id it expects (or one of a set, perhaps) can be
trusted.

>    gave the same result, multiple propspec can be given for it.

Good idea.  Done.

>    the sender's policy is unacceptable (e.g. terminates with "+all").

I don't agree with including that specific example, as it encourages a
particular local policy debate that I don't think this document should
approach.

>    insertion of a new Section 2.4 in this document.

Good point, but rather than doing this, I've added a note to the editor to
make sure the section numbers line up right before publication, in case
they change again.  We can deal with that during the IANA Actions phase of
publication.

> it be a normative reference?
That's a good procedural question.  I think it has to be because it
involves IANA actions that are being amended, but I think this is something
that can be sorted out during IESG Evaluation.

Thanks!

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 06 May 2013 15:25:01 -0700

At 13:43 06-05-2013, Murray S. Kucherawy wrote:
>involves IANA actions that are being amended, but I think this is 
>something that can be sorted out during IESG Evaluation.

I do not have to read RFC 5451 to understand 
draft-ietf-appsawg-rfc5451bis-00 [1].  I read it though.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01365.html

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 07 May 2013 17:42:08 +0200

> "value" because it is usually an FQDN, but we also say that it doesn't have

I cannot think of anything but saying that explicitly.  How about
merging the first two paragraphs?  E.g.:

   Every Authentication-Results header field has an authentication
   service identifier field ("authserv-id" above).  This refers to
   the authenticating service within a given ADMD.  For example, if
   the identifier is similar in syntax to a fully-qualified domain
   name, domain delegation semantics can be used to establish whether
   it belongs to an ADMD's name space.  This specification does not
   mandate how, but the identifier MUST correspond unequivocally to
   the ADMD that generates it and MUST pertain to exactly that one
   ADMD. ...

> Are those not synonymous?

Not quite.  For example, a random number would satisfy the uniqueness
but can hardly refer to an ADMD.

> From the perspective of a module consuming this field, it has to be
> the case that such a module can safely assume that a field bearing
> the authserv-id it expects (or one of a set, perhaps) can be 
> trusted.

Right.  But then associating the field with a specific ADMD becomes
interesting only if you happen to mix the message streams from
multiple ADMDs (e.g. on a MUA).  In that case, /all/ ADMDs have to be
compliant, and they have to agree on interoperable naming conventions.

> particular local policy debate that I don't think this document should

I thought abhorring +all was uncontroversial.

> Thanks!

You're welcome :-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 May 2013 15:35:44 -0700

>    the ADMD that generates it and MUST pertain to exactly that one

I'm about to post a new version with this section reworked a bit.  Let me
know what you think of it.

> but can hardly refer to an ADMD.

Sure it can; NetEase (a Chinese ESP) uses "163.com" as their domain name.
An authserv-id of just "163" would be fine.

> compliant, and they have to agree on interoperable naming conventions.

That's actually only true if you plan to trust the A-R fields added by
other ADMDs.  Most commonly you'll only care about your own.

> I thought abhorring +all was uncontroversial.

Probably, but it's not something this document needs to discuss in order to
be effective.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 May 2013 18:53:31 -0400

Just on one item:

> That's a good procedural question.  I think it has to be because it involves
> IANA actions that are being amended, but I think this is something that can
> be sorted out during IESG Evaluation.

Coupla things:

1. It's usually not necessary for the obsolescent document to be a
normative reference, as the obsoleting document has all the necessary
information.  That's certainly true in this case, and I suggest making
the reference informative.

2. Have I told you how unhappy I am with the citation style you use?
It's generally not something I'm willing to argue about, preferring to
defer to the authors' style of citations, but in this case it seems
particularly bad.  May I suggest this?:

OLD
   [AR-ORIG] defined a new header field for electronic mail messages
   that presents the results of a message authentication effort in a
   machine-readable format.

NEW
   The first edition of this document [RFC5451] defined a new header
   field for electronic mail messages that presents the results of a
   message authentication effort in a machine-readable format.

...and replace all other instances of "[AR-ORIG]" with "[RFC5451]" (or
even just "RFC 5451"; how many citations to the same document do you
need?).

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 07 May 2013 19:01:29 -0400

> I thought abhorring +all was uncontroversial.

Trying to deconstruct an SPF record and make judgments based on it's internal 
structure is 'bad'.  All you can take is the SPF result.  If someone publishes 
v=spf +1, then it's 'pass'.  That's all you know.  There are enough other ways 
to make a functionally equivalent record that it's not worth worrying about.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 May 2013 16:02:24 -0700

> the reference informative.

Did that in -01 (just posted).

> 2. Have I told you how unhappy I am with the citation style you use?

Not until now!

> even just "RFC 5451"; how many citations to the same document do you

Done for the next version.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 May 2013 16:03:51 -0700

> to make a functionally equivalent record that it's not worth worrying
I think the point is that "+all" is a possible example where local policy
at the receiver/verifier might be to downgrade an SPF "pass" to something
less positive.  All of that is true, but I would prefer to be generic in
making the facility available and letting receivers figure out what things
warrant such treatment.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 May 2013 19:14:34 -0400

>> defer to the authors' style of citations

OK, so let me be clear.  Let's please not discuss this further in this
thread, though; if we want to pursue it, let's do it in a separate
thread, or, even better, on the rfc-interest list.

I prefer for citations to be maximally useful, without requiring the
reader to go to the bottom of the document and look at the references
for everything.  That means that the style "[AR-ORIG]" is truly
sub-optimal, because it gives *no* useful information until it's been
looked up at least once.  It also means that "[RFC5451]", by itself,
isn't great either, because, while it tells you where to find the
cited document, it doesn't tell you what it is.  Consider these:

1. "According to [RFC5321], the MAIL FROM command <...etc...>"

2. "According to [SMTP], the MAIL FROM command <...etc...>"

3. "According to SMTP [RFC5321], the MAIL FROM command <...etc...>"

4. "According to Simple Mail Transfer Protocol (SMTP) [RFC5321], the
MAIL FROM command <...etc...>"

In cases (1) and (2), you're requiring the reader to know what RFC
5321 or "SMTP" are, or forcing them to go look up the reference.  In
cases 3 and 4, you give more information: you're citing *both* SMTP
and RFC 5321, and it's much more likely that a reader will know what's
being cited without having to look at the reference.

For citations to this document (well, or the original version, for
now) from elsewhere, one might say something like this:

"The description of the Message Authentication Status header field
[RFC5451], specifies that <...etc...>"

... which seems far superior to citations that simply use bare
"[RFC5451]" or something like "[AUTH-STAT]".

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 08 May 2013 11:35:09 +0200

> know what you think of it.

A couple of nits:

s/contect/context/, and in the sentence:

   For example, [SPF] can base its inclusion on the RFC5321.Helo
   parameter or on the RFC5322.From domain; including both of those
   in the header field makes it impossible for the consumer to
   determine which mode of SPF was applied

s/inclusion/conclusion/, and s/RFC5322.From/RFC5321.MailFrom/.  Maybe
"which parameter was actually used" is clearer than "which mode of SPF
was applied", since SPF lacks a definition of "mode".

On Wed 08/May/2013 01:14:34 +0200 Barry Leiba wrote:>
> [RFC5451], specifies that <...etc...>"

Would it make sense to change the title into:

   *The Authentication-Results Header Field*
?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 May 2013 09:59:03 -0700

> was applied", since SPF lacks a definition of "mode".

Fixed, fixed, and fixed.

>    *The Authentication-Results Header Field*
I don't think that's necessary.

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 May 2013 14:32:43 +0100

On 03/05/2013 22:26, S Moonesamy wrote:
> mailing list before the end of Friday May 17. Comments saying that you 
> reviewed the draft and you are happy for it to be sent for IETF Last 
> Call are also valuable.
>
> Regards,
I just reviewed -01. I believe it is a well written document with good 
and detailed security considerations. Some nits are below:

In Section 2.2:

    Where an SMTP command 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.

This seems to say that the SMTP reference is Normative, because one need 
to be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is 
listed as Informative.

In Section 2.5.4:

  LDAP needs an Informative Reference.

2.5.5.  Extension Result Codes

    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.  Therefore, they are subject
    to change at any time and not suitable for production use.  Any MTA,
    MUA or downstream filter intended for production use SHOULD ignore or
    delete any Authentication-Results header field that includes an
    extension result.

I am mostly curious to see some examples of such extensions.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 May 2013 09:11:32 -0700

> to be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is

OK.

>  LDAP needs an Informative Reference.

Are we sure about that?  It's just an example of a related service that
might cause a temperror for SMTP AUTH.  I could change it to "a directory
service" to avoid having to make that reference.  LDAP's not important to
this specification in any way.  I'll do that, actually.

> I am mostly curious to see some examples of such extensions.

You could make one up and imagine using it.  Barry likes "banana", so:

Authentication-Results: your.example.com; banana=foobar

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 May 2013 17:36:46 +0100

On 14 May 2013, at 17:11, "Murray S. Kucherawy" <[email-masked]> wrote:

> On Tue, May 14, 2013 at 6:32 AM, Alexey Melnikov <[email-masked]> wrote:
>  
> In Section 2.5.4:
> 
> Are we sure about that?  It's just an example of a related service that might cause a temperror for SMTP AUTH.  I could change it to "a directory service" to avoid having to make that reference.  LDAP's not important to this specification in any way.  I'll do that, actually.

I don't particularly care. Any protocol you mention needs a reference though.

> Authentication-Results: your.example.com; banana=foobar

Ok. Are there many of these in the wild?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 May 2013 09:57:58 -0700

On Tue, May 14, 2013 at 9:36 AM, Alexey Melnikov
<[email-masked]>wrote:

> There is no way to know for sure, of course.  Most of the ones I know that
were being tried have since been registered, so I don't personally know of
any that fit in the description of 2.5.5 anymore.

---

From: "John Levine" <[email-masked]>
Date: 14 May 2013 17:49:03 -0000

>Ok. Are there many of these in the wild?

There's one for DMARC, but since there's a WG spinning up that will
presumably document it in an RFC.

I've suggested a few clarifications to Murray, dunno if he's planning
another version soon.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 16 May 2013 15:24:54 +0200

On Tue 14/May/2013 18:57:58 +0200 Murray S. Kucherawy wrote:
> On Tue, May 14, 2013 at 9:36 AM, Alexey Melnikov <[email-masked]> wrote:
> 

One is the DNS White List (dnswl) method, used by Courier (mentioned
in Appendix E).  It writes:

  Authentication-Results: wmail.tana.it;
      dnswl=pass dns.zone=list.dnswl.org
      policy.ip=127.0.9.1
      policy.txt="ietf.org http://dnswl.org/s?s=1703"

Since it was me who suggested to use Authentication-Results, I think
it's up to me to register that.  I'm waiting for this I-D to get
published so as to avail of Designated Expert rather than IETF review.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 May 2013 07:27:00 -0700

> published so as to avail of Designated Expert rather than IETF review.
To be consistent with the other registered methods, the policy.ip and
policy.txt things wouldn't be included.  A-R is meant to provide results
and return details of what visible parts of a message were evaluated (e.g.,
header fields, SMTP properties).  The client IP isn't one of those, nor is
resulting text.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 16 May 2013 17:22:15 +0200

> header fields, SMTP properties).  The client IP isn't one of those, nor is

That's not a client IP, but the return value of the lookup.  Passing
that value to downstream filters is the whole point of adding this
header field, otherwise it would have to be looked up again.  Details
such as DKIM's key length, IMHO, are often in a comment because they
are of minor importance, not because they are not a visible part of
the message.)

The policy.txt is important as it contains a domain name.  Albeit A-R
is not intended to be restricted to domain-based authentication,
that's by far the most common case, a granularity that was settled
many years ago.  By indicating a "somewhat responsible" entity, the
method is semantically consistent with that strategy.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 May 2013 16:54:21 -0700

> method is semantically consistent with that strategy.
What does the reply encode that downstream agents need?  If I know that, I
can suggest something more in line with how A-R was designed to operate.