Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-01.txt

From: [email-masked]
Date: Thu, 19 Feb 2015 21:44:01 -0800

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          : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc7001bis-01.txt
	Pages           : 44
	Date            : 2015-02-19

Abstract:
   This document specifies a message header field called Authentication-
   Results 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 to make sorting and filtering decisions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/

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

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Feb 2015 11:24:04 -0500

On Thursday, February 19, 2015 09:44:01 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          : Murray S. Kucherawy

I've reviewed the draft.  I think it's on the right track, but there's a lot 
of  redundancy between the new words in the new sections 2.3 and 2.5, so that 
could possibly be tightened up.  I'll suggest something if I get some time to 
work it out.

I'm not sure it fully addresses the errata, but it may.

Trying to read both the draft and the registry naively, leads me to think it 
might be confusing.

http://www.iana.org/assignments/email-auth/email-auth.xhtml

I think 2.5 should emphasize that the registry is the canonical location to 
find information about the different methods that can be used with each ptype.  
The list in the draft is merely exemplary.  Part of the "I don't know" in the 
what should it say requires one to look at the registry to figure out.

Definitely on the right track, in fact almost there.

On a related note:

In order to understand the universe of authentication results, it's necessary 
to look at the following RFCs (reference to 5451 is still required since 7001 
doesn't include all the IANA information to establish the initial registries):

RFC 5451 Message Header Field for Indicating Message Authentication Status
RFC 7001 Message Header Field for Indicating Message Authentication Status
RFC 5617 DKIM/ADSP
RFC 6008 DKIM signature identification (header.b)
RFC 6212 Vouch By Reference (VBR)
draft-kucherawy-dmarc-base (DMARC)
RFC 7218 Authentication-Results Registration for S/MIME
RFC 7410 A Property Types Registry for the Authentication-Results Header Field

Seven RFCs to understand one header field seems to me to be a lot.  would it 
make sense to obsolete 5617, 6008, 6212, and 7218 as part of the update and 
create one document that (less DMARC) covers everything?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Feb 2015 13:14:04 -0500

> could possibly be tightened up.  I'll suggest something if I get some time

Thanks for the suggestion.  I'll take another look at it.

> I'm not sure it fully addresses the errata, but it may.

I think it does, but of course I wrote the changes.  I've emailed the
author of the erratum to ask what he thinks.

> what should it say requires one to look at the registry to figure out.

I don't know that what's in this draft is really exemplary, but rather just
contains definitions and seed information as did RFC5451.  But yes, some
text making this more clear would probably be good.

> create one document that (less DMARC) covers everything?

RFC5451 is fully obsoleted by RFC7001, unless one is curious about how the
registries were originally created.

RFC5617 can't be obsoleted by this because that document not only declares
the A-R registry entries for ADSP, but defines ADSP itself.  It seems out
of scope for an A-R revision to obsolete a separate protocol document.

RFC6008, RFC6212 and RFC7218 are all registration actions.  I think those
should be separate, and the registry considered canonical as you've
suggested.  There's no need to consolidate in general, otherwise we'd be
long overdue for a re-issuing of MIME, SMTP, etc. for all the new
registrations that have come along.

RFC7001 and RFC7410 are incorporated into this draft and obsoleted (see the
title page), so those are covered.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2015 02:40:46 -0000

PS: Now that I look at the IANA registry, I see that the property
values are all collected there, but the sources are quite confusing.

For example, it says that for sender-id, the ptype is header and the
property is the header that PRA used, but the source is claimed to be
RFC 4406 which predates A-R.  Where did the IANA registry entry come
from?  

Similarly the domainkeys entries say they're from RFC 4870 which
defines a Domainkey-Status: header but says nothing about A-R.  And
the "auth" results say they're from RFC 4954, ditto.

At the very least the 2.7.x sections in 7001bis should tell you where
the ptypes and properties are defined, and the ones that aren't
actually defined anywhere should be defined there.

R's,
John

---

From: t.petch <[email-masked]>
Date: Mon, 23 Feb 2015 15:49:19 +0000

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 20, 2015 4:24 PM
> create one document that (less DMARC) covers everything?

I think that it is worse than that.  I started with Authentication
Methods, reckoning I needed to be clear on them before Results would
make sense to me.  IANA references 4406, 4408, 4870, 4954, 5617, 5751,
6212, 6376, 6541
 several of which have no IANA section at all  and those that do, mostly
do not mention the Authentication Methods registry.  With hindsight, it
all went wrong with RFC5451 which set up the registry but did not
provide the entries which could be presumed to occur in the earlier
RFC4xxx had the registry been in existence a few years earlier.  So we
start with foundations of sand which were 'built' on by RFC7001 and
...well, I don't know where to go now except a bit more cautiously and
thoroughly than in the past.

Tom Petch

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Feb 2015 11:08:20 -0500

> make sense to me.  IANA references 4406, 4408, 4870, 4954, 5617, 5751,

What entries do you think are missing that RFC5451 should've added?  It did
register methods and results for all of those protocol RFCs (except, of
course, the ones that came after it).

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Feb 2015 11:31:49 -0500

> RFC 4406 which predates A-R.  Where did the IANA registry entry come

RFC5451 created entries for protocols that existed prior to its existence.
The definition of "senderid" and the PRA appear in RFC4406.  So the methods
registry's "sender-id" entry points to RFC4406.

The results registry points to RFC5451 because that's where you go to find
out what (for example) "fail" means.  For things like SPF and SID that
included those definitions, it could go either way, and consensus was to do
what we did here.  For things like DomainKeys and DKIM which didn't define
failure codes, the original reference was RFC5451.

> the "auth" results say they're from RFC 4954, ditto.

Same idea there too; we'd have to reissue all of those RFCs if the rule is
that the protocol document has to also contain all of the places that
protocol might be registered.

> actually defined anywhere should be defined there.

I'm confused.  The known method/property/ptype combinations are enumerated
in the registry, which is what it's for.  Is that not sufficient?

It sounds like you want to add a column to the registry that points back to
the RFC that added each entry.  Is that the case?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 23 Feb 2015 11:50:45 -0500

> registry's "sender-id" entry points to RFC4406.

Oh, right, there they are.  I was confused (and I don't think I'm the only 
one) because 7001 obsoletes 5451, but the IANA considerations section in 
7001 copies the definition text but not the initial values.  It was fine 
not to copy them since they didn't change, but it feels like a cruel joke 
not to remind people that 7001 is missing the good bits.  (I'm happy to 
skip the theological issues about whether one RFC truly obsoletes another 
if you can't implement the new one without also reading the old one.)

> the RFC that added each entry.  Is that the case?

That would certainly help.  Or in the "defined" column in the registry, 
change it to RFC5451 for all the methods that are actually defined there 
and nowhere else.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Feb 2015 12:46:10 -0500

> change it to RFC5451 for all the methods that are actually defined there

RFC 5451 doesn't say much more than is in the registry.  I don't think you 
actually need to read 5451.  You need to read 7001/7001bis and the registry.  
I thought the changes msk made in response to my comments made that clear.

If $CURRENTRFC + registry is enough for implementers, then I think it's 
adequately specified.  Since the standard for addition to the registry is 
expert review, I don't believe there's a guarantee that every item in the 
registry will have a companion RFC.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Feb 2015 13:01:57 -0500

> if you can't implement the new one without also reading the old one.)

I think the goal is that 7001/7001bis plus the registry is complete.  As
Scott correctly notes, we've lowered the bar to Expert Review, so the
registry entries thus created do need to be self-sufficient as much as
possible.

-MSK

---

From: t.petch <[email-masked]>
Date: Mon, 23 Feb 2015 19:00:19 +0000

---- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "John R Levine" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Monday, February 23, 2015 6:01 PM
> registry entries thus created do need to be self-sufficient as much as

When I go to the Methods Registry in IANA and see

domainkeys  [RFC4870] header
sender-id   [RFC4406] header

I have an expectation that those RFC will have an IANA Considerations
that tells me what I need to know, or points me to a section in the RFC
(or another RFC) that does; those RFC have no IANA Considerations at
all.

When I go to the Methods Registry in IANA and see

auth [RFC4954] smtp auth

smime [RFC5751] body smime-part

spf  [RFC4408] smtp helo

I have an expectation that those RFC will have an IANA Considerations
that tells me what I need to know, or points me to a section in the RFC
(or another RFC) that does; those RFC have IANA Considerations but make
no mention of Authentication Methods - again I am left stranded.

What RFC5451 failed to do - and I note that the IANA Methods registry
now contains no mention of this RFC - was to identify itself to IANA as
the point of contact for all those entries, and then RFC5451 should have
contained a further reference to where more detail could be found; and
by more detail I mean the section in the RFC, not just the whole RFC.
This is, after all, what almost all IANA Considerations that I am
familiar do, they tell me which section, e.g. 2.3.6.2, of which RFC to
go to for more detail.

Reading this with a naive eye, which I more or less have, then I think
it too hard to follow.  (Try working out what the name of header field
used by PRA is from RFC4406). Self-sufficient is not the word that comes
to mind.

Tom Petch

> -MSK

------------------------------------------------------------------------
--------

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2015 22:22:07 -0000

>I think the goal is that 7001/7001bis plus the registry is complete.

The registries are, as I understand it, supposed to be collections of
information from other places, with references to the source where you
can find the background, more details, and so forth.

If the registry is corrected to point to 5451 for the entries that are
defined there, and the 2.7.x parts of 7001bis say where to look for
the definitions of the properties and values, I'd be happy.  I realize
that the registry is likely to be updated later to add new entries,
but I doubt that any of the stuff for the existing methods will
change.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Feb 2015 19:18:51 -0500

> but I doubt that any of the stuff for the existing methods will

If something gets added down the line someplace without an RFC, what would
we reference?  We're at Expert Review, not Specification Required.

Do we want to do something that is in effect "Specification Optional"?  It
seems like that would satisfy what you and Tom are saying.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 23 Feb 2015 21:30:30 -0500

> we reference?  We're at Expert Review, not Specification Required.

Whatever we have that explains what it is.  If you look through the 
registries, you'll find URLs, people's e-mail addresses, and occasional 
notes that IANA has a copy of the paper spec if you need to look at it.

In general, there appear to be two kinds of entries in IANA protocol 
registries.  Some are just place holders to reserve a point in the 
namespace for private values, but most are intended to tell you how to 
implement whatever it is so you can interoperate.  In this case, I don't 
see any reason to forbid private place holders, but for all the ones we 
have now, they're supposed to be public and interoperate so as t.p. and I 
have been asking, please give us pointers to enough info to implement 
them.

Regards,

---

From: t.petch <[email-masked]>
Date: Tue, 24 Feb 2015 09:55:06 +0000

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "John Levine" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Tuesday, February 24, 2015 12:18 AM
> we reference?  We're at Expert Review, not Specification Required.

When Expert Review is set up,  then the rules for the review can be
specified as indeed RFC7001 does
"The designated expert has discretion to
   request that a publication be referenced if a clear, concise
   definition of the authentication method cannot be provided such that
   interoperability is assured."

I would have preferred 'stable publication' or some such but think that
what we have will do going forward.

It is looking back, trying to make sense of e.g.

sender-id [RFC4406] header   name of header field used by PRA
or
auth [RFC4954] smtp auth     AUTH parameter of the MAIL command

where I think that RFC5451 should have had a pointer to itself with
either a brief explanation if such could be provided or an onward
reference to the applicable section of the other RFC when necessary.  So
reinstating that part of RFC5451 in rfc7001bis is not a satisfactory
solution in my book (and just where in RFC4406 do I find a list of
applicable header fields?).

RFC7001 has added a layer of confusion IMHO on top of this to which
rfc7001bis adds more.  Sometimes it is necessary to go back and give a
complete explanation rather than deltaing a delta which is a  .... and I
think that that is where we are now.

Tom Petch