[dane] [Errata Held for Document Update] RFC7672 (6283)

[RFC Errata System <[e-mail]>]

The following errata report has been held for document update 
for RFC7672, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6283

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Viktor Dukhovni <[e-mail]>
Date Reported: 2020-09-08
Held by: Paul Wouters (IESG)

Section: 3.2.2

Original Text
-------------
3.2.2.  DANE-TA(2) Name Checks

   To match a server via a TLSA record with certificate usage
   DANE-TA(2), the client MUST perform name checks to ensure that it has
   reached the correct server.  In all DANE-TA(2) cases, the SMTP client
   MUST employ the TLSA base domain as the primary reference identifier
   for matching the server certificate.

   TLSA records for MX hostnames:  If the TLSA base domain was obtained
      indirectly via a "secure" MX lookup (including any CNAME-expanded
      name of an MX hostname), then the original next-hop domain used in
      the MX lookup MUST be included as a second reference identifier.
      The CNAME-expanded original next-hop domain MUST be included as a
      third reference identifier if different from the original next-hop
      domain.  When the client MTA is employing DANE TLS security
      despite "insecure" MX redirection, the MX hostname is the only
      reference identifier.

Corrected Text
--------------
3.2.2.  DANE-TA(2) Name Checks

   To match a server via a TLSA record with certificate usage
   DANE-TA(2), the client MUST perform name checks to ensure that it has
   reached the correct server.  In all DANE-TA(2) cases, the SMTP client
   MUST employ the TLSA base domain as the primary reference identifier
   for matching the server certificate.

   TLSA records for MX hostnames:  If the TLSA base domain was obtained
      indirectly via a "secure" MX lookup (including any CNAME-expanded
      name of an MX hostname), then the original next-hop domain used in
      the MX lookup MUST be included as a second reference identifier.
      The CNAME-expanded original next-hop domain MUST be included as a
      third reference identifier if different from the original next-hop
      domain.  When the client MTA is employing DANE TLS security
      despite "insecure" MX redirection, the TLSA base domain is the only
      reference identifier.

Notes
-----
The first paragraph of 3.2.2 makes it clear that the TLSA base domain is the primary reference identifier in all cases.  The last sentence of the second paragraph inadvertently contradicts this  in the case the the TLSA base domain is a CNAME expansion of the input MX hostname.

The corrected text replaces "... the MX hostname is the only reference identifier" with "... the TLSA base domain is the only reference identifier".

--------------------------------------
RFC7672 (draft-ietf-dane-smtp-with-dane-19)
--------------------------------------
Title               : SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
Publication Date    : October 2015
Author(s)           : V. Dukhovni, W. Hardaker
Category            : PROPOSED STANDARD
Source              : DNS-based Authentication of Named Entities
Area                : Security
Stream              : IETF
Verifying Party     : IESG