RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 7672, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", October 2015

Source of RFC: dane (sec)

Errata ID: 5395
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Matt McCutchen
Date Reported: 2018-06-16
Verifier Name: Benjamin Kaduk
Date Verified: 2018-06-16

Section 2.1.1 says:

   DNS records that would be
   classified "indeterminate" in the sense of [RFC4035] are simply
   classified as "insecure".

It should say:

   DNS records that would be
   classified "indeterminate" in the sense of [RFC4033] are simply
   classified as "insecure".

Status: Held for Document Update (1)

RFC 7672, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", October 2015

Source of RFC: dane (sec)

Errata ID: 6283
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Viktor Dukhovni
Date Reported: 2020-09-08
Held for Document Update by: Paul Wouters
Date Held: 2024-01-16

Section 3.2.2 says:

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.

It should say:

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".

Report New Errata



Advanced Search