[dane] [Technical Errata Reported] RFC7672 (6283)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 08 September 2020 07:29 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313383A0DEF for <dane@ietfa.amsl.com>; Tue, 8 Sep 2020 00:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iGWRzO1oyef for <dane@ietfa.amsl.com>; Tue, 8 Sep 2020 00:29:03 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183813A0E52 for <dane@ietf.org>; Tue, 8 Sep 2020 00:29:02 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 650CBF40765; Tue, 8 Sep 2020 00:28:43 -0700 (PDT)
To: ietf-dane@dukhovni.org, ietf@hardakers.net, rdd@cert.org, kaduk@mit.edu, ogud@ogud.com, warren@kumari.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ietf-dane@dukhovni.org, dane@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200908072843.650CBF40765@rfc-editor.org>
Date: Tue, 8 Sep 2020 00:28:43 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/a0PazogBXqgQnI7Pq5VchmY-njA>
Subject: [dane] [Technical Errata Reported] RFC7672 (6283)
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 07:29:05 -0000

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Viktor Dukhovni <ietf-dane@dukhovni.org>

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

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

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