5. TLSA and DANE Use Cases and Requirements

The different types of certificate associations defined in TLSA are matched with various sections of [RFC6394]. The use cases from Section 3 of [RFC6394] are covered in this document as follows:

• 3.1 CA Constraints -- Implemented using certificate usage 0.

• 3.2 Certificate Constraints -- Implemented using certificate usage 1.

• 3.3 Trust Anchor Assertion and Domain-Issued Certificates -- Implemented using certificate usages 2 and 3, respectively.

The requirements from Section 4 of [RFC6394] are covered in this document as follows:

Multiple Ports -- The TLSA records for different application services running on a single host can be distinguished through the service name and port number prefixed to the host name (see Section 3).

No Downgrade -- Section 4 specifies the conditions under which a client can process and act upon TLSA records. Specifically, if the DNSSEC status for the TLSA resource record set is determined to be bogus, the TLS connection (if started) will fail.

Encapsulation -- Encapsulation is covered in the TLSA response semantics.

Predictability -- The appendices of this specification provide operational considerations and implementation guidance in order to enable application developers to form a consistent interpretation of the recommended client behavior.

Opportunistic Security -- If a client conformant to this specification can reliably determine the presence of a TLSA record, it will attempt to use this information. Conversely, if a client can reliably determine the absence of any TLSA record, it will fall back to processing TLS in the normal fashion. This is discussed in Section 4.

Combination -- Multiple TLSA records can be published for a given host name, thus enabling the client to construct multiple TLSA certificate associations that reflect different assertions. No support is provided to combine two TLSA certificate associations in a single operation.

Roll-over -- TLSA records are processed in the normal manner within the scope of the DNS protocol, including the TTL expiration of the records. This ensures that clients will not latch onto assertions made by expired TLSA records, and will be able to transition from using one public key or certificate usage to another.

Simple Key Management -- The SubjectPublicKeyInfo selector in the TLSA record provides a mode that enables a domain holder to only have to maintain a single long-lived public/private key pair without the need to manage certificates. Appendix A outlines the usefulness and the potential downsides to using this mode.

Minimal Dependencies -- This specification relies on DNSSEC to protect the origin authenticity and integrity of the TLSA resource record set. Additionally, if DNSSEC validation is not performed on the system that wishes to use TLSA certificate bindings, this specification requires that the "last mile" be over a secure transport. There are no other deployment dependencies for this approach.

Minimal Options -- The operating modes map precisely to the DANE use cases and requirements. DNSSEC use is mandatory in that this specification encourages applications to use only those TLSA records that are shown to be validated.

Wildcards -- Wildcards are covered in a limited manner in the TLSA request syntax; see Appendix A.

Redirection -- Redirection is covered in the TLSA request syntax; see Appendix A.