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

[Benjamin Kaduk <[e-mail]>]

On Sat, Jun 16, 2018 at 04:10:28PM -0700, Paul Hoffman wrote:
> This erratum should be rejected. RFC 4035 defines "indeterminate" in 
> 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




> --Paul Hoffman
> 
> On 16 Jun 2018, at 7:29, RFC Errata System wrote:
> 
> > 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 <[e-mail]>
> >
> > 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