DNS Whitelist (DNSWL) Email Authentication Method Extension
draft-vesely-authmethod-dnswl-16

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-vesely-authmethod-dnswl. If any part of this review is inaccurate, please let us know.

IANA has a pending request from the author to use the Expert Review process to make the assignments described in this document. The primary expert for the Email Authentication registries writes, "The DMARC working group has asked the author for improved specifications for the 'dns' ptype, and we're waiting for that to appear (as of last week). I intend to approve this once that prose is satisfactory."

Once we have the expert's approval, we will make the following registrations at https://www.iana.org/assignments/email-auth, all of which are described in draft-vesely-authmethod-dnswl.

Email Authentication Methods (Section 4.1):

Method: dnswl
Definition: [this document]
ptype: dns
property: zone
Value: DNSWL publicly accessible query root domain
Status: Active
Version: 1

Method: dnswl
Definition: [this document]
ptype: policy
property: ip
Value: type A response received (or comma-separated list thereof)
Status: Active
Version: 1

Method: dnswl
Definition: [this document]
ptype: policy
property: txt
Value: type TXT query response
Status: Active
Version: 1

Method: dnswl
Definition: [this document]
ptype: dns
property: sec
Value: one of "yes" for DNSSEC authenticated data, "no" for not signed, or "na" for not applicable
Status: Active
Version: 1

Email Authentication Property Type (Section 4.2):

ptype: dns
Definition: [this document]
Description: The property being reported belongs to the Domain Name System

Email Authentication Result Names (Section 4.3):

Auth Method: dnswl
Code: pass
Specification: [this document]
Status: active

Auth Method: dnswl
Code: none
Specification: [this document]
Status: active

Auth Method: dnswl
Code: temperror
Specification: [this document]
Status: active

Auth Method: dnswl
Code: permerror
Specification: [this document]
Status: active

Because we have a pending request for registration via the Expert Review process, these registrations will be made as soon as we receive notice of expert approval (at which point we will also change this document's IANA state to "IANA OK" in the Datatracker). The references to this document will be updated as necessary when the document is sent to us for processing.

Thank you,

Amanda Baber
Lead IANA Services Specialist

draft-vesely-authmethod-dnswl has been presented to the ISE for
publication as an Informational RFC on the Independent Stream.

The document describes an email authentication method that has been
implemented by the Courier Mail Server and which might be seen in the
wild. The method defined is compliant with RFC 8601.

The document has been discussed in DMARC where most of the debate
focused on the assignment of the code points requested in Section 4.
The three registries touched all use the "expert review" assignment
policy, and this document has been shown to the relevant DEs and is
believed to meet the standards for assignment. Nevertheless, assignment
is subject to final confirmation by the DEs.

Along the way there was considerable discussion with the authors about
how this is *not* an IETF consensus document and therefore not an IETF
specification. The document now reflects that "this document is provided
for information".

A thorough review was provided by Alexey Melnikov (copied below) and the
document has been updated to reflect the discussions between the author
and Alexey.

The ISE also carried out reviews for clarity or purpose and to fix a
number of nits.

The document was updated four times during this process.


== Alexey Melnikov ==

I found this document to be useful addition to RFC series and support
its publication. I have a couple of minor comments:


In Section 2:

    policy.txt: The TXT record, if any.  Multiple records are
                concatenated as usual.  See Section 3 for the resulting
                content and query options.

Please add a reference to an RFC with more details for novice readers
after "concatenated as usual". I only happen to know as I actually
needed to implement this a couple of months ago.


Also, it would be great if there is a field for reporting use of DNSSEC
when retrieving DNS TXT.


In Section 3:

    According to [RFC5782], TXT records describe the reason why IP
    addresses are listed in a DNSWL.  The TXT record is useful if it
    contains the domain name(s).  The domain name would correspond to the
    DNS domain name used by or within the ADMD operating the relevant
    MTA, sometimes called the "organizational domain".  In that case, the
    authentication provided by this method is equivalent to a DKIM
    signature ([RFC6376]) or an SPF check host ([RFC7208]).  When no
    domain names are known, some DNSWLs use a subdomain of .INVALID

You lost me here a bit, as I don't see a use case for this. Can you
maybe add an example showing use of .INVALID?

    ([RFC2606]) where the leftmost label hints at why an address is
    whitelisted given that its operating organization is not known.  If
    the TXT record(s) contain non-ASCII characters, they need to be
    encoded as appropriate.

The last sentence: can you explain what this means and possible add a
reference? Are you suggesting that UTF-8 should be allowed here? If yes,
say so (and add a reference). Or %-encoding (for example)?

== ISE ==

Section 1

OLD
  The present method
NEW
  The method described in this document
END

---

There are some abbreviations that need to be expanded on first use. I
see:

DNSxL
MTA
ADMD

---

Section 1

  In order to smooth
  operations, this document endorses a usage of TXT fields consistent
  with other authentication methods.

I'm not sure abut "endorses". Maybe "describes"?

---

Section 2

  In particular, some DNSBLs are known
  to return special codes to signal over quota, for example
  127.0.0.255.

Do you have a reference for that?

---

Section 3

s/domain name(s)/domain names/

---

A few places you use "IP" as short for "IP address". I think you should
spell it out. For example, Setion 3:

  If no domain names can be responsibly associated
  to a given IP, for example because the IP was added without direct
  involvement of the organization concerned, DNSWLs can use a subdomain
  of .INVALID ([RFC2606]) where the leftmost label hints at why an
  address is whitelisted.

---

People are going to ask about IPv6. Do you have any thoughts?

---

Section 4 needs some work. We need to reduce it to a very precise
description of what we want IANA to do. So I think you could have...

4.  IANA Considerations

  IANA maintains the "Email Authentication Parameters" registry with
  several subregistries.  IANA is requested to make assignments as
  set out in the following sections.

4.1.  Email Authentication Methods

  IANA is requested to create four new entries in the "Email
  Authentication Methods" registry as follows.

  Method|Definition|ptype |property| Value            |Status|Version
  ------+----------+------+--------+-------------------+------+-------
  dnswl |[This.I-D]|dns  |zone    | DNSWL publicly    |active|  1
        |          |      |        | accessible query  |      |
        |          |      |        | root domain      |      |
  dnswl |[This.I-D]|policy|ip      | type A response  |active|  1
        |          |      |        | received (or      |      |
        |          |      |        | comma-separated  |      |
        |          |      |        | list thereof)    |      |
  dnswl |[This.I-D]|policy|txt    | type TXT query    |active|  1
        |          |      |        | response          |      |
  dnswl |[This.I-D]|dns  |sec    | one of "yes" for  |active|  1
        |          |      |        | DNSSEC            |      |
        |          |      |        | authenticated    |      |
        |          |      |        | data, "no" for    |      |
        |          |      |        | not signed, or    |      |
        |          |      |        | "na" for not      |      |
        |          |      |        | applicable        |      |

4.2.  Email Authentication Property Type

  IANA is requested to create a new entry in the "Email Authentication
  Property Types" registry as follows.

    ptype | Definition | Description
  -------+------------+----------------------------------------------
    dns  | [This.I-D] | The property being reported belongs to the
          |            | Domain Name System

4.3.  Email Authentication Result Names

  IANA is requested to create four new entries in the "Email
  Authentication Result Names" registry as follows.

    Auth Method  | Code      | Specification        | Status
  ---------------+-----------+-----------------------+--------
      dnswl      | pass      | [This.I-D]            | active
      dnswl      | none      | [This.I-D]            | active
      dnswl      | temperror | [This.I-D]            | active
      dnswl      | permerror | [This.I-D]            | active