The following errata report has been submitted for RFC8689, "SMTP Require TLS Option".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7705 -------------------------------------- Type: Technical Reported by: Mechiel Lukkien <mech...@ueber.net> Section: 4.2.1 Original Text ------------- 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. Corrected Text -------------- 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. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC8689 (draft-ietf-uta-smtp-require-tls-09) -------------------------------------- Title : SMTP Require TLS Option Publication Date : November 2019 Author(s) : J. Fenton Category : PROPOSED STANDARD Source : Using TLS in Applications Area : Applications and Real-Time Stream : IETF Verifying Party : IESG _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
