Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt

From: [email-masked]
Date: Wed, 07 Feb 2018 19:59:22 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : Message Header Field for Indicating Message Authentication Status
        Author          : Murray S. Kucherawy
	Filename        : draft-ietf-dmarc-rfc7601bis-00.txt
	Pages           : 48
	Date            : 2018-02-07

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-dmarc-rfc7601bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-rfc7601bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-00

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: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Feb 2018 21:11:48 -0800

> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-00

Et voila.  If you go to the "History" tab and request a diff from the
individual -00 to the working group -00, you can see all of the changes
made relative to RFC7601.  Basically it loosens up the language about what
categories of things can be recorded, makes the ABNF changes requested, and
guts some stuff copied from RFC7601 that doesn't need to be there for this
version because it describes registry changes that were already made by
that RFC.

Let me know if I missed anything.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Thu, 08 Feb 2018 20:17:39 +0000

Looks great to me. This allows us to simplify several pieces of ARC and
make the draft easier to follow.

Thank you!

On Wed, Feb 7, 2018 at 21:11 Murray S. Kucherawy <[email-masked]>
wrote:

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

---

From: "John R. Levine" <[email-masked]>
Date: 10 Feb 2018 13:40:04 -0500

Here's some stuff from my EAI authentication draft which it would be nice 
if you could fold in.

In section 1.5, I'd add a section about EAI, pointing to RFCs 6530-2, and 
saying that in EAI messages, you can have UTF-8 most places you can have 
text intended for humans, and U-labels anywhere there is a domain name.

In section 2.2, for EAI messages, local-part and domain-name are updated 
per RFC 6532, in that atext and dtext are redefined as UTF-8 which flows 
through to local-part and domain-name.

In 2.5, an EAI Authentication Identifier can be UTF-8.

In 2.7.1, an EAI header.d can be UTF-8.  This flows through a change to 
6376 which removes the advice to turn domains into A-labels in EAI 
messages.

In 2.7.2, an EAI spf.mailfrom can be UTF-8.

In 2.7.4, an EAI smtp.auth and smtp.mailfrom and smtp.rcptto can be UTF-8.

In 2.7.5, an EAI vbr.md and vbr.mv can be UTF-8.  A body.smime-identifier 
can be UTF-8 if they ever finish updating S/MIME.

In section 5, it'd probably be a good idea to remove existing headers 
where the service identifer would match yours if you turned its A-labels 
into U-labels.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 11 Feb 2018 07:45:17 -0800

On Sat, Feb 10, 2018 at 10:40 AM, John R. Levine <[email-masked]> wrote:

> [...]

Is this stuff in scope for this working group?  This feels a bit like
feature creep.

Or should your draft just modify this one instead of RFC7601?  The changes
are so small that this could go through pretty quickly.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 11 Feb 2018 16:10:53 +0000

>Let me know if I missed anything.

My recollection is that last time around for what became 7601, we collected all the Section 6 information into a single location since that would be the reference in the registry.  It seems odd to me to carry a normative reference to historic RFCs, including the one that this obsoletes.

Maybe it would be better to change this to updates 7601, rather than obsoletes.  Then Section 6 turns into no IANA actions and there can be a single normative reference to 7601.

As usual, I confess I don't always follow all the nuance of IETF specification management, so the above may be wrong, but I think the documents listed in the IANA registry as the reference should actually describe the relevant details.

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 11 Feb 2018 12:15:14 -0500

> are so small that this could go through pretty quickly.

I don't feel strongly but it seems gratuitously cruel to future readers to 
have two updates in a row where we could have published one.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 16 Feb 2018 01:53:37 -0500

> > A New Internet-Draft is available from the on-line Internet-Drafts
...
> Let me know if I missed anything.

On the DCRUP mailing list there has been discussion about adding header.a 
(algorithm) to authentication results.  This is in addition to the discussion 
about adding header.s (selector) for ARC.  The general view there was that 
since there is nothing experimental about those DKIM signature elements, it 
would be better not to have them included in an experimental document.

7601bis seems ideal both technically and timing wise.

I'm attaching both a unified diff of the XML and an RFCdiff of my proposed 
text.  Please review, comment, etc.  I hope this can be included in 7601bis.

Scott K

--- draft-ietf-dmarc-rfc7601bis-00.xml	2018-02-15 21:35:04.515992669 -0500
+++ draft-ietf-dmarc-rfc7601bis-00dsk.xml	2018-02-16 01:47:03.348119368 -0500
@@ -918,17 +918,27 @@
                                             result. </t>
                                 </list> </t>
 
-				<t> DKIM results are reported using a ptype
-				    of "header".  The property, however,
-				    represents one of the tags found in the
-				    DKIM-Signature header field rather than
-				    a distinct header field.  For example,
-				    the ptype-property combination "header.d" 
-				    refers to the content of the "d"
-				    (signing domain) tag from within the
-				    signature header field, and not a distinct
-				    header field called "d". </t>
-
+                                <t> DKIM results are reported using a ptype
+                                    of "header".  The property, however,
+                                    represents one of the tags found in the
+                                    DKIM-Signature header field rather than
+                                    a distinct header field.  For example,
+                                    the ptype-property combination "header.d" 
+                                    refers to the content of the "d"
+                                    (signing domain) tag from within the
+                                    signature header field, and not a distinct
+                                    header field called "d".  In addition to
+                                    previous registrations, this document adds
+                                    DKIM properties for "a" (cryptographic
+                                    algorithm used to sign the message) and
+                                    "s" (selector).  These new properties will
+                                    be used to aid receiver post-verification
+                                    processing.  As an example, 
+                                    <xref target="RFC8301"/> obsoleted use of
+                                    the rsa-sha1 algorithm in DKIM, so it is
+                                    important to be able to distinguish such
+                                    signatures from rsa-sha256.  See <xref
+                                    target="dkimproperties"/>.</t>
 <t>
    The ability to report different DKIM results for a message with
    multiple signatures is described in <xref target="RFC6008"/>. </t>
@@ -1666,7 +1676,35 @@
 
                 <section anchor="name_registry_1"
                      title="&quot;Email Authentication Methods&quot; Registry Description">
-                        <t> No changes are made to this registry. </t>
+                        <t> IANA is requested to make the following additions to
+                            this registry. </t>
+                        
+                        <texttable anchor="dkimproperties"
+                        title="DKIM Property Additions">
+                        <ttcol align="center">METHOD</ttcol>
+                        <ttcol align="left">REF</ttcol>
+                        <ttcol align="left">PTYPE</ttcol>
+                        <ttcol align="center">PROPERTY</ttcol>
+                        <ttcol align="left">VALUE</ttcol>
+                        <ttcol align="left">STATUS</ttcol>
+                        <ttcol align="center">VERS</ttcol>
+
+                        <c>dkim</c>
+                        <c><xref target="DKIM"/></c>
+                        <c>header</c>
+                        <c>a</c>
+                        <c>DKIM signing algorithm</c>
+                        <c>active</c>
+                        <c>1</c>
+        
+                        <c>dkim</c>
+                        <c><xref target="DKIM"/></c>
+                        <c>header</c>
+                        <c>s</c>
+                        <c>DKIM selector</c>
+                        <c>active</c>
+                        <c>1</c>
+                        </texttable>
 		</section>
 				    
                 <section anchor="name_registry_2"
@@ -2346,6 +2384,16 @@
     <seriesInfo name='RFC' value='5518'/>
     <seriesInfo name='DOI' value='10.17487/RFC5518'/>
     </reference>
+                <reference anchor="RFC8301" target='http://www.rfc-editor.org/info/rfc8301'>
+    <front>
+    <title>Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)</title>
+    <author initials='S.' surname='Kitterman' fullname='S. Kitterman'><organization /></author>
+    <date year='2018' month='January' />
+    <abstract><t>   The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision.  This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.</t></abstract>
+    </front>
+    <seriesInfo name='RFC' value='8302'/>
+    <seriesInfo name='DOI' value='10.17487/RFC8301'/>
+    </reference>
         </references>

@@ -2924,6 +2972,9 @@
 
                         <t> Referred to RFC 7328 in the "iprev"                      
                             definition. </t>
+                        
+                        <t> Added IANA registration for DKIM "a" and "s"
+                            properties</t>
 
                         <t> Corrected the "smime-part" prose. </t>

---

From: "John Levine" <[email-masked]>
Date: 16 Feb 2018 22:49:44 -0500

>Let me know if I missed anything.

Seems fine, although I've long found 7601 one of the most mysterious RFCs ever published.

The IANA registry says that there is a dkim header.i property defined
in RFC7601, but the only place it appears in 7601 is in examples in
Appendix B.

Section 2.4 says that a "policy" property is how you report a local
policy that overrides the regular result, but I see policy=reject in
reports about DMARC where it's just copying the p= from the _dmarc
record.  Is that right?  If not, where if anywhere should it be
reported? 

Can we add DKIM header.a here, please?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Feb 2018 20:42:24 +0000

> Seems fine, although I've long found 7601 one of the most mysterious RFCs

Why's that?  (And why wasn't this mentioned when 7601 or any of its
antecedents was in last call?  No errata?)

> in RFC7601, but the only place it appears in 7601 is in examples in

7601 says:

   DKIM results are reported using a ptype of "header".  The property,
   however, represents one of the tags found in the DKIM-Signature
   header field rather than a distinct header field.

So "header.d" means the d= tag, "header.i" means the i= tag, etc.  Those
are the only two identifiers DKIM evaluates, so they're the only ones that
were ever registered.

7601bis loosens the language about what's appropriate to send downstream,
from being only authenticated identifiers to also allowing other related
stuff that downstream agents might want to use or log.  That means things
like "s" and "a" are now in play.

> record.  Is that right?  If not, where if anywhere should it be

That would be "dmarc=fail policy.dmarc-rules=arc-failure", where
"dmarc-rules" and "arc-failure" are things the rejecting operator is free
to invent for its own records.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 19 Feb 2018 13:37:52 -0800

> antecedents was in last call?  No errata?)

I admit I could have been paying more attention.

> are the only two identifiers DKIM evaluates, so they're the only ones that

I get that, but I don't see where they were registered.  I just see the 
examples in the RFC.

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Feb 2018 17:28:28 -0500

> like "s" and "a" are now in play.

Any feedback on the patch I sent you to add them to 7601bis?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 24 Feb 2018 23:41:33 -0800

> Any feedback on the patch I sent you to add them to 7601bis?

Not yet.  As you've seen on the list (I think), I believe adding "a" or any
EAI changes are actually out of scope for this WG, but it seems silly to
spin up two different 7601bis efforts, one for what DMARC needs and one for
other stuff.  (I'm willing to do it in two steps, but I'm probably the only
one who doesn't mind.)

I talked to Barry at M3AAWG about this and I'm waiting to hear back from
Alexey about how we should handle the requests.

-MSK