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

Thu, 15 Feb 2018 22:54:07 -0800 

On Wednesday, February 07, 2018 09:11:48 PM Murray S. Kucherawy wrote:
> On Wed, Feb 7, 2018 at 7:59 PM, <internet-dra...@ietf.org> wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
...
> 
> 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
Title: Diff: draft-ietf-dmarc-rfc7601bis-00.txt - draft-ietf-dmarc-rfc7601bis-00dsk.txt
 draft-ietf-dmarc-rfc7601bis-00.txt   draft-ietf-dmarc-rfc7601bis-00dsk.txt 
DMARC Working Group M. Kucherawy DMARC Working Group M. Kucherawy
Internet-Draft Internet-Draft
Obsoletes: 7601 (if approved) February 15, 2018 Obsoletes: 7601 (if approved) February 16, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: August 19, 2018 Expires: August 20, 2018
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-dmarc-rfc7601bis-00 draft-ietf-dmarc-rfc7601bis-00
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2018. This Internet-Draft will expire on August 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2. Definition and Format of the Header Field . . . . . . . . . . 9 2. Definition and Format of the Header Field . . . . . . . . . . 9
2.1. General Description . . . . . . . . . . . . . . . . . . . 9 2.1. General Description . . . . . . . . . . . . . . . . . . . 9
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9
2.3. Property Types (ptypes) and Properties . . . . . . . . . 12 2.3. Property Types (ptypes) and Properties . . . . . . . . . 12
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15
2.7. Defined Methods and Result Values . . . . . . . . . . . . 15 2.7. Defined Methods and Result Values . . . . . . . . . . . . 15
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 15 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 15
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 20 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 21
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 20 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 21 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . 24 4.1. Header Field Position and Interpretation . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 25 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 27 6.1. The Authentication-Results Header Field . . . . . . . . . 28
6.2. "Email Authentication Methods" Registry Description . . . 27 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . 27 6.3. "Email Authentication Methods" Registry Update . . . . . 28
6.4. "Email Authentication Property Types" Registry . . . . . 27 6.4. "Email Authentication Property Types" Registry . . . . . 28
6.5. "Email Authentication Result Names" Description . . . . . 28 6.5. "Email Authentication Result Names" Description . . . . . 29
6.6. "Email Authentication Result Names" Update . . . . . . . 28 6.6. "Email Authentication Result Names" Update . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 28 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 29
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 30 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 31
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 30 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 30 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 31
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 30 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 31 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 32
7.7. Attacks against Authentication Methods . . . . . . . . . 31 7.7. Attacks against Authentication Methods . . . . . . . . . 32
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 31 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 31 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 32
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 31 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 32
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 32 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Authentication-Results Examples . . . . . . . . . . 36 Appendix B. Authentication-Results Examples . . . . . . . . . . 37
B.1. Trivial Case; Header Field Not Present . . . . . . . . . 36 B.1. Trivial Case; Header Field Not Present . . . . . . . . . 37
B.2. Nearly Trivial Case; Service Provided, but No B.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 37 Authentication Done . . . . . . . . . . . . . . . . . . . 38
B.3. Service Provided, Authentication Done . . . . . . . . . . 37 B.3. Service Provided, Authentication Done . . . . . . . . . . 39
B.4. Service Provided, Several Authentications Done, Single B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.5. Service Provided, Several Authentications Done, Different B.5. Service Provided, Several Authentications Done, Different
MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 39 MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.6. Service Provided, Multi-tiered Authentication Done . . . 41 B.6. Service Provided, Multi-tiered Authentication Done . . . 42
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 43 B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 44
Appendix C. Operational Considerations about Message Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 44 Authentication . . . . . . . . . . . . . . . . . . . 45
Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 45 Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 46
Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 47 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions and/ Agent (MUA) and downstream filters can make filtering decisions and/
or provide a recommendation to the user as to the validity of the or provide a recommendation to the user as to the validity of the
skipping to change at page 16, line 49 skipping to change at page 16, line 49
permerror: The message could not be verified due to some error that permerror: The message could not be verified due to some error that
is unrecoverable, such as a required header field being absent. A is unrecoverable, such as a required header field being absent. A
later attempt is unlikely to produce a final result. later attempt is unlikely to produce a final result.
DKIM results are reported using a ptype of "header". The property, DKIM results are reported using a ptype of "header". The property,
however, represents one of the tags found in the DKIM-Signature however, represents one of the tags found in the DKIM-Signature
header field rather than a distinct header field. For example, the header field rather than a distinct header field. For example, the
ptype-property combination "header.d" refers to the content of the ptype-property combination "header.d" refers to the content of the
"d" (signing domain) tag from within the signature header field, and "d" (signing domain) tag from within the signature header field, and
not a distinct header field called "d". 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, [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 Table 1.
The ability to report different DKIM results for a message with The ability to report different DKIM results for a message with
multiple signatures is described in [RFC6008]. multiple signatures is described in [RFC6008].
[DKIM] advises that if a message fails verification, it is to be [DKIM] advises that if a message fails verification, it is to be
treated as an unsigned message. A report of "fail" here permits the treated as an unsigned message. A report of "fail" here permits the
receiver of the report to decide how to handle the failure. A report receiver of the report to decide how to handle the failure. A report
of "neutral" or "none" preempts that choice, ensuring the message of "neutral" or "none" preempts that choice, ensuring the message
will be treated as if it had not been signed. will be treated as if it had not been signed.
skipping to change at page 27, line 40 skipping to change at page 28, line 21
Header field name: Authentication-Results Header field name: Authentication-Results
Applicable protocol: mail ([MAIL]) Applicable protocol: mail ([MAIL])
Status: Standard Status: Standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [this document] Specification document(s): [this document]
Related information: none Related information: none
6.2. "Email Authentication Methods" Registry Description 6.2. "Email Authentication Methods" Registry Description
No changes are made to this registry. IANA is requested to make the following additions to this registry.
+--------+--------+--------+----------+-------------+--------+------+
| METHOD | REF | PTYPE | PROPERTY | VALUE | STATUS | VERS |
+--------+--------+--------+----------+-------------+--------+------+
| dkim | [DKIM] | header | a | DKIM | active | 1 |
| | | | | signing | | |
| | | | | algorithm | | |
| dkim | [DKIM] | header | s | DKIM | active | 1 |
| | | | | selector | | |
+--------+--------+--------+----------+-------------+--------+------+
Table 1: DKIM Property Additions
6.3. "Email Authentication Methods" Registry Update 6.3. "Email Authentication Methods" Registry Update
No changes are made to this registry. No changes are made to this registry.
6.4. "Email Authentication Property Types" Registry 6.4. "Email Authentication Property Types" Registry
[RFC7410] created the "Email Authentication Property Types" registry. [RFC7410] created the "Email Authentication Property Types" registry.
No changes are made to this registry. However, it should be noted No changes are made to this registry. However, it should be noted
skipping to change at page 35, line 27 skipping to change at page 36, line 27
[PRA] Lyon, J., "Purported Responsible Address in E-Mail [PRA] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006,
<http://www.rfc-editor.org/info/rfc4407>. <http://www.rfc-editor.org/info/rfc4407>.
[RFC7410] Kucherawy, M., "A Property Types Registry for the [RFC7410] Kucherawy, M., "A Property Types Registry for the
Authentication-Results Header Field", RFC 7410, DOI 10 Authentication-Results Header Field", RFC 7410, DOI 10
.17487/RFC7410, December 2014, .17487/RFC7410, December 2014,
<http://www.rfc-editor.org/info/rfc7410>. <http://www.rfc-editor.org/info/rfc7410>.
[RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage
Update to DomainKeys Identified Mail (DKIM)", RFC 8302,
DOI 10.17487/RFC8301, January 2018,
<http://www.rfc-editor.org/info/rfc8301>.
[RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- [RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-
Since Header Field and SMTP Service Extension", RFC 7293, Since Header Field and SMTP Service Extension", RFC 7293,
DOI 10.17487/RFC7293, July 2014, DOI 10.17487/RFC7293, July 2014,
<http://www.rfc-editor.org/info/rfc7293>. <http://www.rfc-editor.org/info/rfc7293>.
[SECURITY] [SECURITY]
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, DOI 10 Text on Security Considerations", BCP 72, RFC 3552, DOI 10
.17487/RFC3552, July 2003, .17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <http://www.rfc-editor.org/info/rfc3552>.
skipping to change at page 46, line 44 skipping to change at page 47, line 44
o RFC 7208 uses all-lowercase result strings now, so adjusted prose o RFC 7208 uses all-lowercase result strings now, so adjusted prose
accordingly. accordingly.
o Updated list of supported methods, and mentioned the registries o Updated list of supported methods, and mentioned the registries
immediately below. immediately below.
o Mentioned that when a local-part is removed, the "@" goes with it. o Mentioned that when a local-part is removed, the "@" goes with it.
o Referred to RFC 7328 in the "iprev" definition. o Referred to RFC 7328 in the "iprev" definition.
o Added IANA registration for DKIM "a" and "s" properties
o Corrected the "smime-part" prose. o Corrected the "smime-part" prose.
o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the
Received fields. Received fields.
o Made minor editorial adjustments. o Made minor editorial adjustments.
Appendix E. Acknowledgments Appendix E. Acknowledgments
The author wishes to acknowledge the following individuals for their The author wishes to acknowledge the following individuals for their
 End of changes. 14 change blocks. 
46 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 
--- 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>
 

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to