Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Apr 2015 10:29:11 -0400

On Sunday, March 29, 2015 02:43:54 PM Alexey Melnikov wrote:
> This message is starting 3 weeks (*) Working Group Last Calls on
> draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for Indicating
> Message Authentication Status). The WGLC ends on
> April 19th.
> 
> Please send your comments on the document in a reply to this message or
> directly to me. If you read the document and you think the document is
> ready for publication, saying so would also be helpful.

I've reviewed the document and believe it's essentially ready for publication.  
I think there is a bit of editorial adjustment needed in the prose about 
different a-r methods.

Here's my list of A-R related RFCs:

RFC 5451/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)
RFC 6577 Sender Policy Framework (SPF)
RFC 7281 Authentication-Results Registration for S/MIME
RFC 7293 The Require-Recipient-Valid-Since Header Field
RFC7489 DMARC

Here's what the draft currently says about different methods:

  At the time of publication of this document, the following are
  published, domain-level email authentication methods in common use:

  o  Author Domain Signing Practices ([ADSP])
  o  SMTP Service Extension for Authentication ([AUTH])
  o  DomainKeys Identified Mail Signatures ([DKIM])
  o  Sender Policy Framework ([SPF])
  o  Vouch By Reference ([VBR])
  o  reverse IP address name validation ("iprev", defined in Section 3)

   In addition, the following are non-standard methods recognized by
   this specification that are no longer common:

  o  DomainKeys ([DOMAINKEYS]) (Historic)
  o  Sender ID ([SENDERID]) (Experimental)

I think the list misses DMARC, S/MIME and RRVS.  I also question the 
description of ADSP and VBR as "common".  Additionally, ADSP is historic.

Instead of getting into a bike shed discussion about what's common and how can 
we tell, what about something like this:

  At the time of publication of this document, the following are
  published, authentication methods:

  o  Author Domain Signing Practices ([ADSP]) (Historic)
  o  Domain-based Message Authentication,  Reporting and Conformance ([DMARC])
  o  DomainKeys ([DOMAINKEYS]) (Historic)
  o  DomainKeys Identified Mail Signatures ([DKIM])
  o  reverse IP address name validation ("iprev", defined in Section 3)
  o  Require-Recipient-Valid-Since Header Field and SMTP Service Extension
       ([RRVS])
  o  SMTP Service Extension for Authentication ([AUTH])
  o  Sender ID ([SENDERID]) (Experimental)
  o  Sender Policy Framework ([SPF])
  o  S/MIME Signature Verification [SMIME-REG]
  o  Vouch By Reference ([VBR])

None of these are marked deprecated in the registry:

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

As a result, I don't think we should treat them differently in the text beyond 
noting the status of the relevant RFC.

Scott K

---

From: t.petch <[email-masked]>
Date: Wed, 8 Apr 2015 17:06:57 +0100

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 08, 2015 3:29 PM
> http://www.iana.org/assignments/email-auth/email-auth.xhtml

Scott

but if you were to look at the updated registry, as for example in the
one I have prepared by hand (but which the IETF mailing system refuses
to post - perhaps I  have upset the Privacy Police:-) then you will find
that domainkeys and DKIM-ADSP are deprecated in the registry.

Tom Petch

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Apr 2015 13:03:35 -0400

Good point. Thanks. 

That still doesn't match the current text. 

Scott

On April 8, 2015 12:06:57 PM EDT, "t.petch" <[email-masked]> wrote:
>> Instead of getting into a bike shed discussion about what's common
>and
>how can

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Apr 2015 10:07:04 -0700

> noting the status of the relevant RFC.

Seems reasonable to me.  I'll do that in the next version, which I won't
submit until WGLC closes.

Tom is correct that the IANA Considerations section does update the
registries appropriately.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Apr 2015 17:32:33 -0400

On April 8, 2015 1:07:04 PM EDT, "Murray S. Kucherawy" <[email-masked]> wrote:
>and how
>> can
>> As a result, I don't think we should treat them differently in the
>text
>> beyond

Great. Given that, it might also warrant a sentence along the lines of "Methods marked as historic are deprecated in this update".

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Apr 2015 15:20:39 -0700

On Wed, Apr 8, 2015 at 2:32 PM, Scott Kitterman <[email-masked]> wrote:

> Great. Given that, it might also warrant a sentence along the lines of
> "Methods marked as historic are deprecated in this update".
>

I'll say something more comprehensive, basically a forward reference to
IANA Considerations.

-MSK

---

From: t.petch <[email-masked]>
Date: Thu, 9 Apr 2015 12:30:54 +0100

I said I would post my hand-crafted revision to the IANA registry to the
list.  I should have said that I would send an e-mail for posting, which
I have now done three times and, as you may have seen, there is nothing
on the mailing list, or in the List Archive.  The e-mail successfully
arrives at another mailbox  with a different ISP so my MTA is fine with
it, looks like the AMS servers are not.  No DSN, nothing, just the
appearance of a black hole.

So I still have it and will e-mail it individually to anyone who wants
it.

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>;
<[email-masked]>
Sent: Sunday, March 29, 2015 4:14 PM

> I think that this I-D is ready to advance.
>
> It has as complex an IANA Considerations as I can recall,
> comprising, depending on how you count, several hundred changes to the
> underlying HTML.  I could not readily tell what the new registries
would
> look like, so I applied the changes, by hand, to the current
registries
> and have the result in
> .mhtml.  The file is 175kbyte (mostly SCRIPT, probably not needed) and
I
> will post that separately in case others want to peruse it.
>
> Picking my words with care, with so much to do, it is possible that
IANA
> will find an alternative interpretation to the one on which the WG has
> consensus.  I have seen that happen before and seen it fixed, without
> having to change the RFC, but cannot recall just how.  It may have
been
> a
> consensus call on the WG List, or even just an e-mail from AD or WG
> Chairs; it might be prudent to have the mechanics of this to hand.
>
> And/or might it be prudent to insert a further check, perhaps after
> 'IANA
> OK', to see what IANA are going to come up with prior to AUTH48?
>
> As you may guess, I am a pessimist (but have learnt that the problems
> that I anticipate are less likely to be problems:-)
>
> Tom Petch
>
> From: "Alexey Melnikov" <[email-masked]>
> Sent: Sunday, March 29, 2015 2:43 PM
> > Alexey,
> > As a co-chair.
> > (*) - this is to allow people to recover from the Dallas IETF.
> >

---

From: t.petch <[email-masked]>
Date: Thu, 16 Apr 2015 15:40:55 +0100

A new consideration:-(

http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced
-status-codes.xhtml#smtp-enhanced-status-codes-3

X.7.25 has a reference of [Section 3 of RFC7001]   (although I am not
clear why).

Perhaps that will need updating.

Tom Petch

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: "IETF Apps Discuss" <[email-masked]>
Sent: Wednesday, April 08, 2015 10:32 PM
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05

> >>   o  Domain-based Message Authentication,  Reporting and
Conformance
> >> ([DMARC])
> >>   o  reverse IP address name validation ("iprev", defined in
Section
> >3)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Apr 2015 09:03:47 -0700

> X.7.25 has a reference of [Section 3 of RFC7001]   (although I am not

RFC7001 is, as far as I'm aware, the only place where the common reverse IP
check done by MTAs is defined, hence the reference.

Good catch; -06 will take care of this.

-MSK

---

From: t.petch <[email-masked]>
Date: Fri, 17 Apr 2015 09:13:02 +0100

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Scott Kitterman" <[email-masked]>; "IETF Apps Discuss"
<[email-masked]>
Sent: Thursday, April 16, 2015 5:03 PM
> Good catch; -06 will take care of this.

I have a sense of deja vu - all over again!

When I follow the references from X.7.25, RFC7372 says no more than that
which is already in the IANA entry while the reference to RFC7001 takes
me to a paragraph that I read, and re-read and think 'eh?'  A bit like
going straight from IANA to the domainkeys RFC for authentication
results, something you have now fixed in rfc7001bis.

Reading section 3 thereof, for iprev, there is nothing about X.7.25 - is
it really the right RFC?  well yes, RFC7372 says so, but I read the
'iprev' paragraph as something that might happen when an MUA EHLOs an
MSA, in which case I struggle to see how an Authentication-Results
header will ever get into an e-mail. Reverse DNS is fine, it is the way
it fits into e-mail that I struggle with.

So, like domainkeys, I think another sentence or two is needed in
section 3 to bridge the gap between what is in IANA and the text which
that takes you to for further explanation.

Tom Petch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Apr 2015 10:47:39 -0700

> results, something you have now fixed in rfc7001bis.

X.7.25 is a code one might return if the "iprev" test fails and the MTA
chooses to reject the message rather than let it pass.  If rejecting,
RFC7001 doesn't apply (obviously) other than being the only place in the
RFC series that there's currently a definition of what the "iprev" check is
in the first place.

> it fits into e-mail that I struggle with.

Does the above clarify?  If so, then I guess there are two things I could
do here:

1) Basically explain this in a subsection of the "iprev" definition, but
that seems an odd thing to do.

2) Put the definition of "iprev" into its own document, and then have
X.7.25 and this document point to that one.

-MSK

---

From: t.petch <[email-masked]>
Date: Sat, 18 Apr 2015 09:56:04 +0100

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Scott Kitterman" <[email-masked]>; "IETF Apps Discuss"
<[email-masked]>
Sent: Friday, April 17, 2015 6:47 PM
> X.7.25 and this document point to that one.

Murray

Unless there are a lot of enthusiastic supporters of 'iprev' out there,
then I think that another document is overkill, making things more
complex than they need be.  Yet having the IANA registry for X.7.25
point to a paragraph, a document,  that has no mention of X.7.25 -
well, seems underkill.   A single sentence with X.7.25 in it would
satisfy me. It doesn't matter much what the sentence says, just having
it there so that a follower of the reference from the IANA website knows
that they have landed in the right place and now must understand what it
says.

Tom Petch

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2015 16:17:34 -0000

>satisfy me.

For me, the main reason we're doing 7001bis is that several of the
current IANA registry entries point to documents that don't actually
define the thing in the registry, but rather something else that the
registry item uses.

So long as we find all the dangling references, describing them in
7001bis and pointing the registry at 7001bis should solve the problem.

R's,
John