Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-02.txt

From: [email-masked]
Date: Sun, 12 May 2013 21:53:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : Message Header Field for Indicating Message Authentication Status
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc5451bis-02.txt
	Pages           : 42
	Date            : 2013-05-12

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc5451bis-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 18:22:47 -0400

On Sunday, May 12, 2013 09:53:42 PM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area Working
> Group Working Group of the IETF.
> 
> 	Title           : Message Header Field for Indicating Message
> Authentication Status Author(s)       : Murray S. Kucherawy

Comments:

>    At the time of publication of this document, Author Domain Signing
>    Practices ([ADSP]), SMTP Service Extension for Authentication
>    ([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, Sender
>    Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are
>    published DNS domain-level email authentication methods in common
>    use.  DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are also
>    referenced here, though they respectively have "Historic" and
>    "Experimental" status, and are no longer common.

I've also seen iprev in the wild and it's supported by the python authres 
module I helped develop.  We've also implemented DMARC based on the latest 
draft.  Iprev is in 5451, so I think it should be mentioned.

>    Although SPF defined a header field called "Received-SPF" and
>    DomainKeys defined one called "DomainKey-Status" for this purpose,
>    those header fields are specific to the conveyance of their
>    respective results only and thus are insufficient to satisfy the
>    requirements enumerated below.  In addition, many SPF implementations
>    have adopted the header field specified below, and DomainKeys has
>    been obsoleted by DKIM.

I think this overstates things with respect to SPF.  Most implementations have 
not adopted authres and even in the cases where they have, it's an option, not 
the default.

In the ABNF:

I believe the change from:

authres-header = "Authentication-Results:" [CFWS] authserv-id
	[ CFWS version ]

to:

authres-header = "Authentication-Results:" [CFWS] authserv-id	
	[ [CFWS] "/" [CFWS] authres-version ]

is an incompatible change and if you really want to make it, you should bump 
the version number.  I checked and with authres, your example is mis-parsed.

	Authentication-Results: example.org/1; none

In this example, the authserv-id is "example.org", but authres, using the RFC 
5451 ABNF parses this and determines the authserv-id is "example.org/1"

If you want to make this change, I think it needs to be version 2 because an 
existing version 1 parser can't parse the header field anymore.  Actually, I'm 
not sure that helps since a version 1 parser would fail to determine the 
message version.  I think you need to specif a minimum of one space between 
the authserv-id and the "/" for backward compatibility.

The first two are editorial.  The last one is significant.  It's possible we 
implemented it wrong in authres, but that's how it looks for the moment.  
Let's discuss.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 May 2013 16:06:53 -0700

> draft.  Iprev is in 5451, so I think it should be mentioned.
OK.

> not adopted authres and even in the cases where they have, it's an option,

Seems to me adding "at least as an option" with respect to the SPF
implementations is probably sufficient.

> implemented it wrong in authres, but that's how it looks for the moment.
I made that change on two premises:

1) I've yet to see a single implementation that includes a version number
in its output, though there are some that do look for it.  It seems to me
it's a safe change to make on that basis.

2) The way versioning is done at that point in the header field is
inconsistent with where it's done adjacent to the methods.  It's nicer on
the eyes and easier for parsers if they're done the same way.  I consider
this a bug in RFC5451.  I never opened an erratum for this before just
fixing it in the -bis draft, but I think I probably should have.

I'd hate to see this recycle at PS just for this change, so either I can
back it out, or we could call it a bug fixed in this draft and leave the
version alone.  Although you're correct that strictly speaking it's
incompatible, it only affects consumers regarding a currently unused
protocol feature.

Does anyone else have an opinion here?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 19 May 2013 05:21:16 -0000

>it's a safe change to make on that basis.

Mine does, but there probably aren't five people in the world other
than me using it.

>incompatible, it only affects consumers regarding a currently unused

Hmmn.  Let's say I have a mail server farm generating 5451 A-R headers
and the guy down the hall has a filtering/sorting/delivering farm
interpreting them.  Then someone shows up with 5451bis. I am a good
doobie and update my software to comply with 5451bis which, since I am
only using authentication schemes described in 5451, merely involves
adding /1 after the authserv-id.  I hear the sound of screaming from
the other end of the hall as the unexpected slash breaks the
filtering.

Frankly, I'd lose the slash.  Whether or not it was a mistake to leave
it out in the first place, adding it now only creates a gratuitous
incompatibility.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 May 2013 07:52:18 -0700

> the other end of the hall as the unexpected slash breaks the

You don't have to change anything in a generator to remain compliant.  The
"/1" is optional if the version number isn't actually changing.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 19 May 2013 11:09:26 -0400

> "/1" is optional if the version number isn't actually changing.

Right, but if I do add the /1, consumers that haven't upgraded will break 
even though nothing substantive has changed.

If there were something substantively different between 5451 and bis, so 
that consumers had to change to consume something other than the version 
number, I would probably be OK with the slash.  But in this case, the 
slash doesn't solve any problem I can see, and is likely to cause some 
interop issues.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 May 2013 00:14:06 -0700

Hi Alexey,

Scott Kitterman mentioned [1] that the following:

  'is an incompatible change and if you really want to make it, you should
   bump the version number.  I checked and with authres, your example is
   mis-parsed.

   In this example, the authserv-id is "example.org", but authres, using the
   RFC 5451 ABNF parses this and determines the authserv-id is "example.org/1"'

Murray Kucherawy commented that he has "yet to see a single 
implementation that includes a version number in its output, though 
there are some that do look for it" [2].  John Levine responded that 
his implementation does [3].  He also mentioned that the introduction 
of the slash (see ABNF) creates an incompatibility.

There is also the following in Section 5 of draft-ietf-appsawg-rfc5451bis-02:

   "An MTA SHOULD remove any instance of this header field bearing a
    version (express or implied) that it does not support."

Will the addition of the slash cause an interoperability issue?

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09460.html
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09463.html
3. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09465.html

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 May 2013 04:04:36 -0400

> 3. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09465.html

If an implementation based on 5451 receives a future 5451bis header field with 
an authserv-id of example.com and a version number of 2, it would read that as 
an authserv-id of example.com/2 and an implicit version number of 1.

Both getting the version number wrong and the authserv-id wrong could have 
interoperability implications.

Scott K

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 21 May 2013 22:32:04 +0100

> Will the addition of the slash cause an interoperability issue?

It looks like it might. I haven't implemented the spec yet (although I 
intend to), so this would not affect my [yet-to-be-written] implementation.

> Regards,
> S. Moonesamy
>
> 1. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09460.html
> 2. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09463.html
> 3. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09465.html
>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 22 May 2013 10:11:10 +0100

You know, as I think about this, my key question is why remove it?

If that's not essential, then we can just have future versions use a
different header field name, so instead of:

Authentication-Results: example.org/2 [...]

We have:

Authentication-Results-2: example.org [...]

A simplistic M*A might be confused by the presence of the first, but surely
would simply ignore the presence of the second form?

Dave

---

From: Dave Cridland <[email-masked]>
Date: Wed, 22 May 2013 11:57:06 +0100

> You know, as I think about this, my key question is why remove it?
Alexey pointed out I was being unclear. I meant removal of the header, as
in this paragraph from the draft:

> A simplistic M*A might be confused by the presence of the first, but
> surely would simply ignore the presence of the second form?
>
> Dave
>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 May 2013 08:46:37 -0400

Dave Cridland <[email-masked]> wrote:

>surely

Did you mean "why not remove it"?

Scott K

---

From: Dave Cridland <[email-masked]>
Date: Wed, 22 May 2013 14:47:34 +0100

> Did you mean "why not remove it"?

I've been overtaken by events, actually - hadn't caught up with all my mail
and had missed -04 being published - my comments are probably irrelevant.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 23 May 2013 09:50:55 +0200

> authres-header = "Authentication-Results:" [CFWS] authserv-id

Note that in bis-04 it is:

 authres-header = "Authentication-Results:" [CFWS] authserv-id
        [ [CFWS] authres-version ]

The optional space allows:

   Authentication-Results: example.org1; none

> existing version 1 parser can't parse the header field anymore.

STD 68 specifies how to define a formal syntax, but that doesn't have
to be a first-order syntax, so its parseability can depend on the
semantics.  The ABNF rules defined in the I-D don't lend themselves to
automated generation of lexical analyzers:  In order to parse the
identifier and understand which ADMD it refers to, it is necessary to
adhere to some naming convention, which is purposely left unspecified.

---

From: "John Levine" <[email-masked]>
Date: 23 May 2013 15:41:24 -0000

>        [ [CFWS] authres-version ]

You're right. Adding the brackets is clearly a mistake since it makes
it impossible to tell where the authserv-id ends and the
authres-version starts.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 May 2013 08:47:48 -0700

> it impossible to tell where the authserv-id ends and the

huh?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Thu, 23 May 2013 12:56:48 -0400

>> it impossible to tell where the authserv-id ends and the

I think John means that the change makes the second CFWS optional, and
that can't be.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 May 2013 10:11:28 -0700

> I think John means that the change makes the second CFWS optional, and

Barry, while your explanation does nicely restate the syntactic utility 
of the brackets, the semantics of your explanation are completely 
different from what John wrote.  So forgive me if press for John to 
confirm that he merely mistyped or elaborate on his meaning something else.

d/

---

From: "John R Levine" <[email-masked]>
Date: 23 May 2013 13:15:25 -0400

>> it impossible to tell where the authserv-id ends and the

Authentication-Results: foobar1 ; ...

Is that authserv-id foobar1, or authserv-id foobar and authres-version 1 ?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 May 2013 15:40:41 -0700

Yep, oversight from when I removed the "/".  I'll fix it now in source and
post a new version since my shepherd also found a few nits during his
review.

On Thu, May 23, 2013 at 10:15 AM, John R Levine <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>