Updates to and Operational Guidance for the DANE Protocol
draft-ietf-dane-ops-12

#x27;s certificate
   chain (either the default chain or the certificate that was selected
   based on the SNI information provided by the client).

   Given the DNSSEC validated DNS records below:

   example.com.               IN MX 0 mail.example.com.
   mail.example.com.          IN A 192.0.2.1
   _25._tcp.mail.example.com. IN TLSA 2 0 1 (
                                 E8B54E0B4BAA815B06D3462D65FBC7C0
                                 CF556ECCF9F5303EBFBB77D022F834C0 )

   The TLSA base domain is "mail.example.com" and is required to be the
   HostName in the client's SNI extension.  The server certificate chain
   is required to be be signed by a trust anchor with the above
   certificate SHA2-256 digest.  Finally, one of the DNS names in the
   server certificate is required to be be either "mail.example.com" or

Dukhovni & Hardaker     Expires December 4, 2015               [Page 23]
Internet-Draft               DANE operations                   June 2015

   "example.com" (this additional name is a concession to compatibility
   with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details).

   The semantics of wildcards in server certificates are left to
   individual application protocol specifications.

10.3.  Design Considerations for Protocols Using DANE

   When a TLS client goes to the trouble of authenticating a certificate
   chain presented by a TLS server, it will typically not continue to
   use that server in the event of authentication failure, or else
   authentication serves no purpose.  Some clients may, at times,
   operate in an "audit" mode, where authentication failure is reported
   to the user or in logs as a potential problem, but the connection
   proceeds despite the failure.  Nevertheless servers publishing TLSA
   records MUST be configured to allow correctly configured clients to
   successfully authenticate their TLS certificate chains.

   A service with DNSSEC-validated TLSA records implicitly promises TLS
   support.  When all the TLSA records for a service are found
   "unusable", due to unsupported parameter combinations or malformed
   associated data, DANE clients cannot authenticate the service
   certificate chain.  When authenticated TLS is dictated by the
   application, the client SHOULD NOT connect to the associated server.
   If, on the other hand, the use of TLS is "opportunistic", then the
   client SHOULD generally use the server via an unauthenticated TLS
   connection, but if TLS encryption cannot be established, the client
   MUST NOT use the server.  Standards for DANE specific to the
   particular application protocol may modify the above requirements, as
   appropriate, to specify whether the connection should be established
   anyway without relying on TLS security, with only encryption but not
   authentication, or whether to refuse to connect entirely.
   Application protocols need to specify when to prioritize security
   over the ability to connect under adverse conditions.

11.  Note on DNSSEC Security

   Clearly the security of the DANE TLSA PKI rests on the security of
   the underlying DNSSEC infrastructure.  While this document is not a
   guide to DNSSEC security, a few comments may be helpful to TLSA
   implementers.

   With the existing public CA PKI, name constraints are rarely used,
   and a public root CA can issue certificates for any domain of its
   choice.  With DNSSEC, under the Registry/Registrar/Registrant model,
   the situation is different: only the registrar of record can update a
   domain's DS record in the registry parent zone (in some cases,
   however, the registry is the sole registrar).  With many gTLDs, for

Dukhovni & Hardaker     Expires December 4, 2015               [Page 24]
Internet-Draft               DANE operations                   June 2015

   which multiple registrars compete to provide domains in a single
   registry, it is important to make sure that rogue registrars cannot
   easily initiate an unauthorized domain transfer, and thus take over
   DNSSEC for the domain.  DNS Operators SHOULD use a registrar lock of
   their domains to offer some protection against this possibility.

   When the registrar is also the DNS operator for the domain, one needs
   to consider whether the registrar will allow orderly migration of the
   domain to another registrar or DNS operator in a way that will
   maintain DNSSEC integrity.  TLSA Publishers SHOULD ensure their
   registrar publishes a suitable domain transfer policy.

   DNSSEC signed RRsets cannot be securely revoked before they expire.
   Operators should plan accordingly and not generate signatures with
   excessively long duration periods.  For domains publishing high-value
   keys, a signature lifetime of a few days is reasonable, and the zone
   should be resigned daily.  For domains with less critical data, a
   reasonable signature lifetime is a couple of weeks to a month, and
   the zone should be resigned weekly.  Monitoring of the signature
   lifetime is important.  If the zone is not resigned in a timely
   manner, one risks a major outage and the entire domain will become
   bogus.

12.  Summary of Updates to RFC6698

   o  In Section 3 we update [RFC6698] to specify a requirement for
      clients to support at least TLS 1.0, and to support SNI.

   o  In Section 5.1 we update [RFC6698] to specify peer identity
      matching and certificate validity interval based solely on the
      basis of the TLSA RRset.  We also specify DANE authentication of
      raw public keys [RFC7250] via TLSA records with Certificate Usage
      DANE-EE(3) and selector SPKI(1).

   o  In Section 5.2 we update [RFC6698] to require that servers
      publishing digest TLSA records with a usage of DANE-TA(2) MUST
      include the trust-anchor certificate in their TLS server
      certificate message.  This extends to the case of "2 1 0" TLSA
      records which publish a full public key.

   o  In Section 5.3 and Section 5.4, we explain that PKIX-EE(1) and
      PKIX-TA(0) are generally NOT RECOMMENDED.  With usage PKIX-TA(0)
      we note that clients may need to processes extended trust chains
      beyond the first trusted issuer, when that issuer is not self-
      signed.

Dukhovni & Hardaker     Expires December 4, 2015               [Page 25]
Internet-Draft               DANE operations                   June 2015

   o  In Section 7, we recommend that DANE application protocols specify
      that when possible securely CNAME expanded names be used to derive
      the TLSA base domain.

   o  In Section 8, we specify a strategy for managing TLSA records that
      interoperates with DANE clients regardless of what subset of the
      possible TLSA record types (combinations of TLSA parameters) is
      supported by the client.

   o  In Section 9, we specify a digest algorithm agility protocol.

   o  In Section 10.1 we recommend against the use of Full(0) TLSA
      records, as digest records are generally much more compact.

13.  Operational Considerations

   The DNS time-to-live (TTL) of TLSA records needs to be chosen with
   care.  When an unplanned change in the server's certificate chain and
   TLSA RRset is required, such as when keys are compromised or lost,
   clients that cache stale TLSA records will fail to validate the
   certificate chain of the updated server.  TLSA RRsets should have
   TTLs that are short enough to limit unplanned service disruption to
   an acceptable duration.

   The signature validity period for TLSA records should also not be too
   long.  Signed DNSSEC records can be replayed by an MiTM attacker
   provided the signatures have not yet expired.  Shorter signature
   validity periods allow for faster invalidation of compromised keys.
   Zone refresh and expiration times for secondary nameservers often
   imply a lower bound on the signature validity period.  See
   Section 4.4.1 of [RFC6781].

14.  Security Considerations

   Application protocols that cannot make use of the existing public CA
   PKI (so called non-PKIX protocols), may choose not to implement
   certain PKIX-dependent TLSA record types defined in [RFC6698].  If
   such records are published despite not being supported by the
   application protocol, they are treated as "unusable".  When TLS is
   opportunistic, the client may proceed to use the server with
   mandatory unauthenticated TLS.  This is stronger than opportunistic
   TLS without DANE, since in that case the client may also proceed with
   a plaintext connection.  When TLS is not opportunistic, the client
   MUST NOT connect to the server.

   Therefore, when TLSA records are used with protocols where PKIX does
   not apply, the recommended policy is for servers to not publish PKIX-
   dependent TLSA records, and for opportunistic TLS clients to use them

Dukhovni & Hardaker     Expires December 4, 2015               [Page 26]
Internet-Draft               DANE operations                   June 2015

   to enforce the use of (albeit unauthenticated) TLS, but otherwise
   treat them as unusable.  Of course, when PKIX validation is supported
   by the application protocol, clients SHOULD perform PKIX validation
   per [RFC6698].

15.  IANA Considerations

   This specification requires no support from IANA.

16.  Acknowledgements

   The authors would like to thank Phil Pennock for his comments and
   advice on this document.

   Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded
   me into participating in DANE working group discussions.  Thanks to
   Paul Hoffman who motivated me to produce this document and provided
   feedback on early drafts.  Thanks also to Samuel Dukhovni for
   editorial assistance.

17.  References

17.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

Dukhovni & Hardaker     Expires December 4, 2015               [Page 27]
Internet-Draft               DANE operations                   June 2015

   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
              Extension Definitions", RFC 6066, January 2011.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify
              Conversations about DNS-Based Authentication of Named
              Entities (DANE)", RFC 7218, April 2014.

17.2.  Informative References

   [I-D.ietf-dane-smtp-with-dane]
              Dukhovni, V. and W. Hardaker, "SMTP security via
              opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-18
              (work in progress), May 2015.

   [I-D.ietf-dane-srv]
              Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
              Based Authentication of Named Entities (DANE) TLSA Records
              with SRV Records", draft-ietf-dane-srv-14 (work in
              progress), April 2015.

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781, December
              2012.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, June 2013.

   [RFC7250]  Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
              T. Kivinen, "Using Raw Public Keys in Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7250, June 2014.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, December 2014.

Dukhovni & Hardaker     Expires December 4, 2015               [Page 28]
Internet-Draft               DANE operations                   June 2015

Authors' Addresses

   Viktor Dukhovni
   Unaffiliated

   Email: ietf-dane@dukhovni.org

   Wes Hardaker
   Parsons
   P.O. Box 382
   Davis, CA  95617
   US

   Email: ietf@hardakers.net

Dukhovni & Hardaker     Expires December 4, 2015               [Page 29]