Subject: Re: [dane] [Technical Errata Reported] RFC6698 (3594)

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Sep 2016 14:36:56 -0400

Hello all,

So, this errata was filed, but it seems never officially closed out -
RFC6698 was updated by RFC7671 - "The DNS-Based Authentication of
Named Entities (DANE) Protocol: Updates and Operational Guidance".

What would the WG (especially the submitter) like us to do with this
errata? I *think* that it can be rejected, but that feels like a
process issue. Hold for update feels like it might be best, even
though it's been done?

W

On Tue, Apr 16, 2013 at 6:18 PM, RFC Errata System
<[email-masked]> wrote:
> The following errata report has been submitted for RFC6698,
> "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6698&eid=3594
>
> --------------------------------------
> Type: Technical
> Reported by: Viktor Dukhovni <[email-masked]>
>
> Section: 2.1.1
>
> Original Text
> -------------
>       2 -- Certificate usage 2 is used to specify a certificate, or the
>       public key of such a certificate, that MUST be used as the trust
>       anchor when validating the end entity certificate given by the
>       server in TLS.  This certificate usage is sometimes referred to as
>       "trust anchor assertion" and allows a domain name administrator to
>       specify a new trust anchor -- for example, if the domain issues
>       its own certificates under its own CA that is not expected to be
>       in the end users' collection of trust anchors.  The target
>       certificate MUST pass PKIX certification path validation, with any
>       certificate matching the TLSA record considered to be a trust
>       anchor for this certification path validation.
>
> Corrected Text
> --------------
>       2 -- Certificate usage 2 is used to specify a certificate, or the
>       public key of such a certificate, that MUST be used as the trust
>       anchor when validating the end entity certificate given by the
>       server in TLS.  This certificate usage is sometimes referred to as
>       "trust anchor assertion" and allows a domain name administrator to
>       specify a new trust anchor -- for example, if the domain issues
>       its own certificates under its own CA that is not expected to be
>       in the end users' collection of trust anchors.  The target
>       certificate MUST pass PKIX certification path validation, with any
>       certificate matching the TLSA record considered to be a trust
>       anchor for this certification path validation.  Since clients cannot
>       be presumed to have their own copy of the trust-anchor certificate,
>       when the TLSA association specifies a certificate digest, the TLS
>       server MUST be configured to provide the trust-anchor certificate in
>       its "certificate_list" TLS handshake message.
>
>
> Notes
> -----
> This is critical for interoperability between clients and servers.  A client that commits to verify TLSA RR certificate associations will fail if it can't obtain the required certificates.  With usage "2" there is no presumption that these are available to the client.  If servers are not obligated to provide them the protocol will consistently fail.  With non-interactive protocols where there is no user to "click OK", such as SMTP, there is no good work-around and both client and server owners suffer.
>
> Instructions:
> -------------
> This errata 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 (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6698 (draft-ietf-dane-protocol-23)
> --------------------------------------
> Title               : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
> Publication Date    : August 2012
> Author(s)           : P. Hoffman, J. Schlyter
> Category            : PROPOSED STANDARD
> Source              : DNS-based Authentication of Named Entities
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 13 Sep 2016 23:53:38 +0000

> Named Entities (DANE) Protocol: Updates and Operational Guidance".

Which addressed the issue by adding the missing requirement.

> process issue. Hold for update feels like it might be best, even

I am not familiar with (and not terribly interested in) process
issues.  The erratum is moot.  Do as you think best.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Sep 2016 20:28:51 -0400

> Which addressed the issue by adding the missing requirement.
Yup.

> issues.  The erratum is moot.  Do as you think best.

Yeah, this is entirely process wonkery; I just didn't want the WG to be
surprised / to give y'all a chance to express a preference (if anyone has
one).

W

>
> --
>         Viktor.
>
> _______________________________________________
> dane mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf