Found 1 record.

Status: Reported (1)

RFC 8689, "SMTP Require TLS Option", November 2019

Errata ID: 7705
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mechiel Lukkien
Date Reported: 2023-11-20

Section 4.2.1 says:

   4.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate as specified in
       [RFC6125] or [RFC7672], as applicable.  The hostname from the MX
       record lookup (or the domain name in the absence of an MX record
       where an A record is used directly) MUST match the DNS-ID or CN-
       ID of the certificate presented by the server.

It should say:

   4.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate as specified in
       [RFC6125] or [RFC7672], as applicable.

Notes:

The second sentence tries to explain/summarize the policies found in the RFCs referenced in the first sentence, about PKIX and DANE. But the explanation seems to accidentally sets new requirements that contradict behaviour specified by DANE: With DANE-EE TLSA records, no specific hostname validation must be done, instead verification is done based on (hash of) SPKI/entire certificate. (DANE-TA hostname verification is also a bit more nuanced). Since the requirements are accurately explained in the RFCs referenced in the first sentence, it seems better to completely remove the second sentence.

I would also like to point out that implementers may want to take care not to treat the situation where all TLSA records are "unusable" (as explained in DANE RFCs) as "authenticated with DANE", in line with "[...] or it MUST be verified successfully using DANE [...]" on line 197.

Report New Errata