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 <[email protected]>
> >
> > 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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
