Subject: [dane] [Technical Errata Reported] RFC7672 (5395)

From: RFC Errata System <[email-masked]>
Date: Sat, 16 Jun 2018 07:29:46 -0700 (PDT)

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:
http://www.rfc-editor.org/errata/eid5395

--------------------------------------
Type: Technical
Reported by: Matt McCutchen <[email-masked]>

Section: 2.1.1

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

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

Notes
-----

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Jun 2018 10:40:04 -0400

The reported erratum is correct, the text should have been as "Corrected".

> On Jun 16, 2018, at 10:29 AM, RFC Errata System <[email-masked]> wrote:
> 

-- 
	Viktor.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 16 Jun 2018 16:10:28 -0700

This erratum should be rejected. RFC 4035 defines "indeterminate" in 
Section 4.4.3. RFC 4035 and RFC 4033 define "indeterminate" differently.

--Paul Hoffman

On 16 Jun 2018, at 7:29, RFC Errata System wrote:

> "SMTP Security via Opportunistic DNS-Based Authentication of Named 
> Entities (DANE) Transport Layer Security (TLS)".
>
> Title               : SMTP Security via Opportunistic DNS-Based 
> Authentication of Named Entities (DANE) Transport Layer Security (TLS)

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Jun 2018 18:29:16 -0500

> Section 4.4.3. RFC 4035 and RFC 4033 define "indeterminate" differently.

This statement is in the context of resolving the discrepancy; the
full context is:

   A DNS lookup may signal an error or return a definitive answer.  A
   security-aware resolver MUST be used for this specification.
   Security-aware resolvers will indicate the security status of a DNS
   RRset with one of four possible values defined in Section 4.3 of
   [RFC4035]: "secure", "insecure", "bogus", and "indeterminate".  In
   [RFC4035], the meaning of the "indeterminate" security status is:

      An RRset for which the resolver is not able to determine whether
      the RRset should be signed, as the resolver is not able to obtain
      the necessary DNSSEC RRs.  This can occur when the security-aware
      resolver is not able to contact security-aware name servers for
      the relevant zones.

   Note that the "indeterminate" security status has a conflicting
   definition in Section 5 of [RFC4033]:

      There is no trust anchor that would indicate that a specific
      portion of the tree is secure.

   In this document, the term "indeterminate" will be used exclusively
   in the [RFC4035] sense.  Therefore, obtaining "indeterminate" lookup
   results is a (transient) failure condition, namely, the inability to
   locate the relevant DNS records.  DNS records that would be
   classified "indeterminate" in the sense of [RFC4035] are simply
   classified as "insecure".

It's clear that the last statement is intended to contrast the two
senses, so the 4033 reference is correct.

-Benjamin

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 16 Jun 2018 16:38:03 -0700

My apologies: you are correct. The erratum is fine. I remembered the 
discussion leading to this text incorrectly.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Jun 2018 20:26:11 -0400

> On Jun 16, 2018, at 7:10 PM, Paul Hoffman <[email-masked]> wrote:
> 
> This erratum should be rejected. RFC 4035 defines "indeterminate" in Section 4.4.3.

(That'd be section 4.3, for anyone reading along).

> RFC 4035 and RFC 4033 define "indeterminate" differently.

Actually, the erratum is correct.  RFC7672 uses the definition
from "RFC4035", and the intent was to make it clear that the
definition of "indeterminate" from RFC4033 is not used.  Rather,
what 4033 calls "indeterminate", "7672" considers (more aptly)
"insecure".  The original text erroneously distanced itself from
4035 instead of 4033.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Jun 2018 23:14:47 -0400 (EDT)

> Original Text

Whether original or corrected text, what it does here worried me more.

The RFC opens with:

 	Abstract

 	This memo describes a downgrade-resistant protocol [...]

Not really downgrade-resistant if I can just strip some RRSIGs from
the packets to make it fail open. So this text is confusing.

But it does make that clear in 2.1.2:

 	If any DNS queries used to locate
 	TLSA records fail (due to "bogus" or "indeterminate" records,
 	timeouts, malformed replies, SERVFAIL responses, etc.), then the SMTP
 	client MUST treat that server as unreachable and MUST NOT deliver the
 	message via that server.

I'm not sure if that's worth bringing into the errata. If we have the
errata as is, it might actually mislead developers into thiking they
must treet an indeterminate response as insecure and use it for TLSA.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 17 Jun 2018 23:21:18 -0400

> On Jun 17, 2018, at 11:14 PM, Paul Wouters <[email-masked]> wrote:
> 

I don't think that's a plausible risk.  That said, in the next
year or two, with soon 5 years of implementation experience behind
us, it may be time to publish an update the clarifies the murkier
corners of 7671/7672 or even a pair of bis rewrites.  Though it
might be tricky for lack of a working group in which to do so.
Perhaps UTA could work, though it too might be shut down by then.

-- 
	Viktor.