[dane] [Errata Rejected] RFC6698 (3594)

[RFC Errata System <[e-mail]>]

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Viktor Dukhovni <[e-mail]>
Date Reported: 2013-04-16
Rejected by: Stephen Farrell (IESG)

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
-----
As per discussion on the DANE WG list, this was overtaken by events and so is rejected.


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.
 --VERIFIER NOTES-- 
   As per discussion on the DANE WG list, this was overtaken by events and so is rejected.

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