[Uta] [Technical Errata Reported] RFC8689 (7705)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 20 November 2023 12:23 UTC

To: fenton@bluepopcorn.net, superuser@gmail.com, francesca.palombini@ericsson.com, leifj@sunet.se, valery@smyslov.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: mechiel@ueber.net, uta@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20231120122324.86C7C19D44CF@rfcpa.amsl.com>
Date: Mon, 20 Nov 2023 04:23:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/BJMW63Fr2PN16NaZK23tDYQ8CzA>
Subject: [Uta] [Technical Errata Reported] RFC8689 (7705)
Precedence: list

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 <mechiel@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

Re: [Uta] [Technical Errata Reported] RFC8689 (77… Jim Fenton
[Uta] [Technical Errata Reported] RFC8689 (7705) RFC Errata System