Subject: [apps-discuss] Extending Authentication-Results again

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Mar 2014 10:06:11 +0000

Given Franck's draft and the SMTP-specific work going on in DANE, it looks
like we're going to want the ability to report things via
Authentication-Results (RFC7001) beyond what it's currently capable of
reporting.  Specifically, there's one token in the ABNF that is constrained
to report things about the envelope, headers, body, or local policy issues
only; it can't easily report things about keys, certificates, DANE results,
etc.  DANE is doing work specifically on SMTP now.

It looks like the simplest path forward is a small ABNF change with a
matching IANA action to create a small registry of legal values.  Since
this WG processed RFC7001, it seems appropriate to handle this change as
well.  Unfortunately, this won't be backward-compatible with RFC7001, so
we're looking at a "v=2" kind of deal.

Can I get a show-of-hands of who will be willing and able to provide
comments and reviews on such a work item?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 06 Mar 2014 10:22:06 -0500

>comments and reviews on such a work item?

Since TLS is about the channel, not the message we can shove this under policy and call it good (as Franck suggests).  I think it's better to avoid the version bump if we can.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 11 Mar 2014 17:50:51 +0100

On Thu 06/Mar/2014 16:22:06 +0100 Scott Kitterman wrote:
>> this WG processed RFC7001, it seems appropriate to handle this change
>> as well.  Unfortunately, this won't be backward-compatible with RFC7001,
>> so we're looking at a "v=2" kind of deal.
>>
> Since TLS is about the channel, not the message we can shove this
> under policy and call it good (as Franck suggests).  I think it's
> better to avoid the version bump if we can.

For a different opinion, I think names like cert.verification are
better than the more convolute policy.certverification, also
considering what the "policy" ptype was meant for.  So, yes, I'd bump
the version number.

Since this seems to be a somewhat recurring situation, I propose to
relax hard-coding the possible ptypes.  Adding a new ptype shouldn't
require a version bump, just like adding a new method doesn't.  In
that case, I suggest that the absence of a version imply version "2",
starting with the new version.  That would be the only substantial
incompatibility with how existing, valid header fields are going to be
parsed under different versions.

Apologies for the delayed reply, I'm not following this list so
closely in this period.

Ale

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 19 Mar 2014 14:12:35 -0400

> comments and reviews on such a work item?

I would and I believe I've thought through how we can have our cake and eat it 
too.

If we make a version 2 that has an IANA registry bounded list of ptypes, but 
keep the "no version specified means version 1" and specify that version 2 
SHOULD only be used in the auth-results header field if a version 2 feature 
(i.e. a new pytpe) is used in the filed, then existing operations aren't 
disturbed and existing implementations ought to ignore these new pytpes 
without issue (if a current implementation tries to process a version 2 header 
field and breaks in the process, I think the implementer gets to keep both 
halves).

I'd even write this draft if you want.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 19 Mar 2014 18:56:09 -0000

>comments and reviews on such a work item?

Sure.

>, there's one token in the ABNF that is constrained

The other alternative is to loosen the specs and say that if an A-R
parser sees a clause it doesn't understand, it should either skip
ahead to the next semicolon and try the next clause or give up.  How
likely is it that there are any existing A-R parsers that will do
something actively bad with a ptype it doesn't understand?

For maximal backward compatibility the thing adding the A-R header can
add two of them, one A-R classic and one with the new stuff.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Mar 2014 11:56:41 -0700

> field and breaks in the process, I think the implementer gets to keep both

I'm not sure we can use a SHOULD in this way, but otherwise we certainly
could encourage implementers to do what you're saying.  Thanks for the
suggestion.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 24 Mar 2014 13:09:37 +0100

> field and breaks in the process, I think the implementer gets to keep both 

I don't understand to whom and for what it would be useful to know the
exact version number.  John's suggestion to skip stanzas with unknown
ptypes looks more practical.  A record's version can still be derived
by analyzing what ptypes are actually present there.

> I'd even write this draft if you want.

It'd be enough to have Franck's draft relax the ptype:  It is already
marked up as <rfc ... updates="7001">.

Ale

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 24 Mar 2014 10:55:39 -0400

>by analyzing what ptypes are actually present there.

As currently defined, unknown ptypes are an error. I agree with msk that we need to bump the version number to do this.  Fortunately, I think if we do it in the way I suggest, it's essentially backwards compatible. 

Starting in RFC 5451, the mechanism for describing feature changes is the version number and it applies to the entire header field. Changing that now could cause interoperability problems since it would change errors to thing that should silently be ignored. 

>marked up as <rfc ... updates="7001">.

As above, I don't think it's that easy. I don't know if it ends up in it's own draft or not.  It's easy enough to copy and paste it later into Franck's draft if that's the right answer. 

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 24 Mar 2014 11:53:20 -0400

On March 24, 2014 10:55:39 AM EDT, Scott Kitterman <[email-masked]> wrote:
>>> without issue (if a current implementation tries to process a
>version
>>2 header 
>>> field and breaks in the process, I think the implementer gets to
>keep
>>both 
>>> halves).
>>
>As currently defined, unknown ptypes are an error. I agree with msk
>that we need to bump the version number to do this.  Fortunately, I
>think if we do it in the way I suggest, it's essentially backwards
>compatible. 
>
>Starting in RFC 5451, the mechanism for describing feature changes is
>the version number and it applies to the entire header field. Changing
>that now could cause interoperability problems since it would change
>errors to thing that should silently be ignored. 

I double checked and the Python module I helped develop raises an error on unknown ptypes, so this isn't just theoretical.

https://launchpad.net/authentication-results-python

Scott K

---

From: "John Levine" <[email-masked]>
Date: 24 Mar 2014 17:38:42 -0000

>https://launchpad.net/authentication-results-python

It also raises an error on an unsupported version number, so you lose
with an A-R header with extended syntax either way.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 24 Mar 2014 15:39:14 -0400

On Monday, March 24, 2014 17:38:42 John Levine wrote:
> >I double checked and the Python module I helped develop raises an error on
> >unknown ptypes, so this isn't just theoretical.
> >

I think that's the correct thing to do.  If we take my approach, the 
unsupported version number only appears in header fields that contain data that 
it can't parse anyway, so even with the extension, existing records could be 
processed by existing code.  If you don't bump the version and change the ABNF 
to allow new ptypes, it's going to be a syntax error, not an error because the 
version isn't understood.

In any case, I think the defined mechanism for extending beyond the existing 
ABNF is bump the version.  If we wanted something like SPF and modifiers where 
unknown modifiers are ignored, I think that had to be in 5451 for version 1.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 25 Mar 2014 17:08:41 +0100

On Mon 24/Mar/2014 15:55:39 +0100 Scott Kitterman wrote:
>>> If we make a version 2 that has an IANA registry bounded list
>>> of ptypes, but keep the "no version specified means version 1"
>>> and specify that version 2 SHOULD only be used in the
>>> auth-results header field if a version 2 feature (i.e. a new
>>> pytpe) is used in the filed, then existing operations aren't 
>>> disturbed and existing implementations ought to ignore these
>>> new pytpes without issue (if a current implementation tries to
>>> process a version 2 header field and breaks in the process, I
>>> think the implementer gets to keep both halves).
>>
>> I don't understand to whom and for what it would be useful to
>> know the exact version number.  John's suggestion to skip stanzas
>> with unknown ptypes looks more practical.  A record's version can
>> still be derived by analyzing what ptypes are actually present
>> there.
> 

I agree we need to bump the version number.  To mandate that the
version number be explicitly written on each record is not needed.

> Starting in RFC 5451, the mechanism for describing feature changes
> is the version number and it applies to the entire header field.
> Changing that now could cause interoperability problems since it
> would change errors to thing that should silently be ignored.

It is common practice to silently ignore syntax errors in mail
headers.  It can be useful if an A-R validator issues a warning upon
finding an unknown-ptype syntax error.  Even then, it shouldn't abort
parsing, unless running in pedantic-mode, strict-version-1 checking,
don't load sub-modules, or similar tweaks.

Ale