RFC 6394

RFC 6394: Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) 💖

okay bestie, so the title block says this is from the IETF, written by R. Barnes at BBN Technologies. It's an Informational doc from October 2011, with ISSN 2070-1721. It's not a Standards Track spec, just published for info 📚. The block doesn't list anything it obsoletes or updates, so it just stands on its own ✨

Abstract 🎀

Lots of apps use the certificate-based auth stuff in Transport Layer Security (TLS) so clients can check that a server really is who it says it is for a domain name. Usually that's PKIX certificate chains rooted in well-known certificate authorities (CAs), but the DNS itself can add extra info too 🌸 This doc lays out use cases where the DNS and DNS Security Extensions (DNSSEC) could make assertions to support the TLS auth process. The main focus is TLS server auth, but it also covers TLS client auth for apps where clients are identified by domain names 💅

Status of This Memo 📝

This doc is not an Internet Standards Track spec. It's published for informational purposes 🦋

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🫶

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6394 💜

Copyright Notice ©️

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this doc. Code Components extracted from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🙈

Table of Contents 🗺️

1. Introduction ....................................................2
2. Definitions .....................................................4
3. Use Cases .......................................................4
   3.1. CA Constraints .............................................5
   3.2. Service Certificate Constraints ............................6
   3.3. Trust Anchor Assertion and Domain-Issued Certificates ......7
   3.4. Delegated Services .........................................9
4. Other Requirements .............................................10
5. Acknowledgements ...............................................11
6. Security Considerations ........................................11
7. References .....................................................11
   7.1. Normative References ......................................11
   7.2. Informative References ....................................12

1. Introduction ✨

Transport Layer Security (TLS) is the base for the security features in tons of modern Internet app service protocols, giving you secure client-server connections [RFC5246]. It's what powers secure HTTP and secure email [RFC2818] [RFC2595] [RFC3207], and it gives hop-by-hop security in real-time multimedia and instant-messaging protocols [RFC3261] [RFC6120] 💖

App service clients usually set up TLS connections to app servers that are identified by DNS domain names. How you get that "source" domain depends on the app [RFC6125]. Someone might type it in, or the client might find it through an automated discovery process like an SRV or NAPTR record 🧚 Once the client has the server's address from an A or AAAA DNS record, it does a TLS handshake, and during that the server shows a PKIX certificate [RFC5280]. The TLS layer checks the PKIX stuff, including that the certificate chains up to one of the client's trust anchors. If that check passes, the app layer then decides whether the DNS name in the certificate for the app service matches the source domain name [RFC6125]. Usually, if the name matches, the client carries on with the TLS connection 🔥

The CAs that issue PKIX certificates are basically asserting bindings between domain names and the public keys they certify. App service clients verify those bindings and make the call on whether to go ahead with connections based on them 👑

So clients count on CAs to correctly assert bindings between public keys and domain names, meaning the holder of the matching private key should be the domain holder. Right now, an attacker can authenticate as a given app service domain if they can get a "mis-issued" certificate from one of the widely used CAs. That's a certificate with the victim's app service domain name and a public key whose private key the attacker holds 😭 If the attacker can also sneak in as a "man in the middle" between client and server (for example, through DNS cache poisoning of an A or AAAA record), then the attacker can convince the client that a server of their choosing legit represents the victim's app service 💀

With DNSSEC [RFC4033] now around, DNS name resolution can give its info securely, in the sense that clients can check that the DNS info came from the domain operator and wasn't messed with in transit 🌈 The goal of DNS-based Authentication of Named Entities (DANE) is to use the DNS and DNSSEC to share extra info about the cryptographic credentials tied to a domain. That way clients can get more assurance out of the TLS handshake 🦋 This doc describes use cases that capture specific goals for using the DNS like this, plus a set of requirements the final DANE mechanism should meet ✨

And yes, this doc will often use HTTPS as the example app service, but DANE is meant to apply equally to every app that uses TLS to connect to app services identified by domain names 🎀

2. Definitions 📖

This doc also uses standard PKIX, DNSSEC, and TLS terminology. For those terms, see RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC 5246 [RFC5246] respectively. Terms about TLS-protected app services and DNS names come from RFC 6125 [RFC6125] 💅

Note in particular that "server" in this doc means the server role in TLS, not a host. Several servers of this type can be co-located on one physical host, often on different ports, and each of them can use different certificates 🫶

This doc refers a bunch of times to the idea of a "domain holder." That means the entity authorized to control the contents of a particular zone. For example, the registrants of 2nd- or 3rd-level domains are the holders of those domains. The holder of a domain isn't necessarily the entity that operates the zone 🍓

Also, a valid DNSSEC signature in a DNS reply doesn't necessarily mean the domain holder authorized the records that signature protects. The difference between a domain's holder and the operator of its zone has several security implications, and the individual use cases below talk about them 🙈

3. Use Cases 🧁

In this section we go over the major use cases the DANE mechanism should support. This list isn't meant to cover every possible way the DNS could support TLS auth. It's the specific cases that make up the initial goals for DANE 💜

In the use cases below, we'll mention these dramatis personae:

• Alice: The operator of a TLS-protected app service on the host alice.example.com, and the administrator of the corresponding DNS zone.
• Bob: A client connecting to alice.example.com.
• Charlie: A well-known CA that issues certificates with domain names as identifiers.
• Oscar: An outsourcing provider that operates TLS-protected app services on behalf of customers.
• Trent: A CA that issues certificates with domain names as identifiers, but isn't generally well-known.

These use cases are framed around adding verification steps to TLS server identity checking on the part of app service clients. In apps where clients are also identified by domain names (like Extensible Messaging and Presence Protocol (XMPP) server-to-server connections), the same considerations and use cases apply to the app server's checking of identities in TLS client certificates 🌸

3.1. CA Constraints ✨

Okay so, Alice runs a website on alice.example.com and got her certificate from the well-known CA Charlie 🎀. She's lowkey worried that other well-known CAs might issue certificates for alice.example.com without her say-so, and clients would just accept them 😭. So she wants a way for visitors to know they should expect alice.example.com to use a certificate issued under her CA (Charlie) and not some other CA. Basically, Alice is recommending that the client verify there's a valid certificate chain from the server certificate to Charlie before accepting the server certificate 💅. (For example, in the TLS handshake, the server might include Charlie's certificate in the server Certificate message's certificate_list structure [RFC5246].)

When Bob connects to alice.example.com, he uses this mechanism to check that the certificate the server showed him was issued under the proper CA, Charlie 🦋. He also does the normal PKIX validation for this certificate, especially making sure it chains to a trust anchor (which could be Charlie's CA, if Bob accepts Charlie's CA as a trust anchor).

Alice might also want to share this info with an external CA operator, Charlie 🧚. Before Charlie issues a certificate for alice.example.com to someone claiming to be Alice, Charlie needs to confirm that Alice is actually the one asking. Alice could indicate her preferred CA using DANE to CAs as well as relying parties. Charlie could then check whether Alice said her certificates should be issued by Charlie or by another CA. Note that this check doesn't guarantee the exact entity requesting a certificate from Charlie actually represents Alice -- it only shows that Alice has authorized Charlie to issue certificates for her domain to properly authorized individuals 🙈.

In principle, DANE information expressing CA constraints can be presented with or without DNSSEC protection. Presenting DANE information without DNSSEC protection doesn't introduce any new vulnerabilities, but it doesn't add much assurance either 🥲. Deleting records removes the protection this constraint provides, but the client is still protected by CA practices (as now). Injected or modified false records aren't useful unless the attacker can also get a certificate for the target domain. So in the worst case, messing with these constraints raises the risk of false authentication only to the level that's standard today 🌸.

Using DANE information for CA constraints without DNSSEC gives a very small extra security feature, ngl 💀. Lots of common attacks against TLS connections already require the attacker to inject false A or AAAA records to steer the victim client to the attacker's server. An attacker who can already inject false DNS records can also provide fake DANE information (without DNSSEC) by just spoofing the additional records needed to carry it.

Injected or modified false DANE information of this type can be used for denial of service, even if the attacker doesn't have a certificate for the target domain. But if an attacker can modify the DNS responses a target host receives, there are already much simpler ways to deny service, like giving a false A or AAAA record 🍓. In that case DNSSEC isn't helpful, since an attacker could still cause a denial of service by blocking all DNS responses for the target domain.

Continuing to require PKIX validation also limits how much DNS operators (as distinct from the holders of domains) can interfere with TLS authentication through this mechanism 👑. Like we said above, even if a DNS operator falsifies DANE records, it can't pretend to be the target server unless it can also get a certificate for the target domain. Main character protection, iykyk 💜.

3.2. Service Certificate Constraints ✨

Alice runs a website on alice.example.com and got a certificate from the well-known CA Charlie 🎀. She's concerned about extra, unauthorized certificates being issued by Charlie, and by other CAs too 😤. She'd like to give visitors a way to know they should expect alice.example.com to present a specific certificate. In TLS terms, Alice is letting Bob know that this specific certificate must be the first certificate in the server Certificate message's certificate_list structure [RFC5246] 🔥.

When Bob connects to alice.example.com, he uses this mechanism to check that the certificate the server presented is the correct one ✨. He also does the normal PKIX validation for this certificate, especially making sure it chains to a trust anchor.

The security implications for this case are the same as for the "CA Constraints" case above 🫶.

3.3. Trust Anchor Assertion and Domain-Issued Certificates ✨

Alice wants to generate and use certificates for her website on alice.example.com without involving an external CA at all 🦋. She can already make her own certificates today, like self-signed certificates and possibly certificates subordinate to those. But when Bob gets one of these in a TLS handshake, he doesn't automatically have a way to check that the issuer really is Alice, because he doesn't necessarily have Alice's corresponding trust anchor 😬. That's a problem for him, because an attacker could present a different certificate and run a man-in-the-middle attack. Bob would really like to protect against this.

So Alice wants to publish info so visitors to her site can know the certificates her application services present are legitimately hers 💖. When Bob connects to alice.example.com, he uses this info to check that the certificate the server presented was issued by Alice. Since Bob can bind certificates to Alice this way, he can use Alice's CA as a trust anchor for validating certificates for alice.example.com. Alice can also recommend that clients accept only her certificates, using the CA constraints described above 🎀.

Just like in Section 3.1 above, Alice might want to share this info with potential third-party CAs (Charlie) as well as relying parties (Bob) 🧚. Publishing a certificate in a DANE record of this form authorizes the holder of the matching private key to represent alice.example.com. So a CA that gets a request to issue a certificate from alice.example.com could use the DANE info to verify the requestor is authorized to receive a certificate for that domain. For example, a CA might choose to issue a certificate for a given domain name and public key only when the holder of the domain name has provisioned DANE info with a certificate containing that public key 🔑.

Note that this use case is functionally equivalent to the one where Alice doesn't issue her own certificates, but uses Trent's CA, which is not well-known 🌈. In that case, Alice would be telling Bob to treat Trent as a trust anchor for validating Alice's certificates, instead of a CA Alice runs herself. So Bob would need a way to securely get Trent's trust anchor info, and that's exactly what DANE info gives him 🫶.

Alice advertising trust anchor material this way doesn't guarantee Bob will accept it 🙃. For example, Bob might have out-of-band info (like a pre-existing local policy) saying that the CA Alice advertised (Trent's CA) isn't trustworthy. That would lead him to not accept Trent as a trust anchor, and so reject Alice's certificate if it was issued under Trent's CA 🚫.

Providing trust anchor material this way clearly needs DNSSEC 🔐, since corrupted or injected records could let an attacker make clients trust the attacker's certificate (assuming some other local policy doesn't reject that certificate). Deleted records will only cause connection failure and denial of service. Though, this could also get clients re-connecting without TLS (a downgrade attack), depending on the application 😭. So for this use case to be safe, applications must forbid clients from falling back to unsecured channels when records appear to have been deleted (for example, when a missing record has no NSEC or NSEC3 record).

By the same token, this use case puts the most power in the hands of DNS operators 👑. Since the operator of the right DNS zone has de facto control over the zone's content and signing, they can create false DANE records that bind a malicious party's certificate to a domain. This risk is especially important when the operator of a DNS zone is a different entity from the holder of the domain, like in DNS hosting or outsourcing arrangements. In those cases, the DNS operator might be able to make changes to a domain that the holder of the domain never authorized 💀.

It's worth noting that DNS operators already have the ability to get certificates for domains under their control, under certain CA policies 🙈. In the current system, CAs need to verify that an entity requesting a certificate for a domain is actually the legitimate holder of that domain. Typically, this is done using info published about that domain, like WHOIS email addresses or special records inserted into a domain. By manipulating these values, DNS operators can get certificates from some well-known certificate authorities today without the true domain holder's authorization 🥀.

3.4. Delegated Services 🎀

Okay so bestie, this one is about outsourcing 🫶 Imagine Oscar runs alice.example.com for Alice. Like, he's the one running the show, so he basically has de facto control over which certificates get shown during TLS handshakes for alice.example.com. Iconic, but also kind of a lot 💅

CA constraints and certificate constraints can still help here, not just against a CA messing up. They can also limit which certificates an outsourcing provider is allowed to use. ✨

There are a few ways the DNS-based TLS certificate info could be set up, and it all depends on who holds the keys to the DNS kingdom 👑

1. Alice keeps the A/AAAA records in her DNS and can sign them along with the DANE record. The catch? Oscar and Alice have to be super coordinated if the addresses or the certificates change 😭
2. Alice delegates a sub-domain name to Oscar. Oscar's DNS handles it all, and Alice has zero control over the A/AAAA, DANE, or anything else under Oscar's side 🙈
3. Alice puts the DANE records in her DNS server but delegates the address records to Oscar's DNS server. So Alice still controls which certificates get used, and Oscar can move the servers around whenever he wants 🦋 The only coordination needed is when the certificates change, and that depends on how the DANE record is set up (like, a CA or an end-entity certificate pointer).

Which pattern a deployment uses decides what kind of constraints each actor can express 🧚 When Alice controls the DANE records (patterns 1 and 3), she can use CA and certificate constraints to control which certificates Oscar presents for her application services. For example, Alice might require Oscar to use certificates under a given set of CAs. The catch is that Alice has to update the DANE records whenever Oscar needs to change certificates 💀

When Oscar controls the DANE records, Oscar gets more autonomy from Alice, but Alice can't enforce any requirements on the certificates Oscar presents in TLS handshakes. Main character energy for Oscar, not so much for Alice 🌸

4. Other Requirements 🌈

Okay, so on top of all the use cases above, DANE has to pass a bunch of lower-level operational and protocol requirements and goals. Let's go through them 💖

Multiple Ports: DANE should be able to support multiple application services with different credentials on the same named host, told apart by port number.

No Downgrade: An attacker who can mess with DNS responses MUST NOT be able to make a DANE-compliant client treat a site that has deployed DANE and DNSSEC like a site that has deployed neither. Not on my watch 😤

Encapsulation: If there's DANE information for the name alice.example.com, it MUST only affect application services hosted at alice.example.com. Boundaries, bestie 🚧

Predictability: Client behavior in response to DANE information MUST be defined in the DANE specification as precisely as possible, especially when DANE information might conflict with PKIX information. No vibes-based behavior allowed 🔥

Opportunistic Security: The DANE mechanism MUST allow a client to figure out whether DANE information is available for a site, so the client can provide the highest level of security possible for a given application service. Clients that don't support DANE SHOULD keep working as specified, whether or not DANE information is present. Everybody gets along 🫶

Combination: The DANE mechanism MUST allow multiple DANE statements of the above forms to be combined. For example, a domain holder should be able to say that clients should accept a particular certificate (Section 3.2) as well as any certificate issued by its own CA (Section 3.3). The precise types of combination allowed will be defined by the DANE protocol. Mix and match, but make it make sense 🎀

Roll-over: The DANE mechanism MUST allow a site to transition from one DANE mechanism to another. For example, a domain holder should be able to migrate from using DANE to assert a domain-issued certificate (Section 3.3) to using DANE to require an external CA (Section 3.1), or the other way around. The DANE mechanism MUST also allow roll-over between records of the same type, e.g., when changing CAs. Glow-up rules ✨

Simple Key Management: DANE SHOULD have a mode in which the domain holder only needs to maintain a single long-lived public/private key pair. One key to rule them all 🗝️

Minimal Dependencies: It SHOULD be possible for a site to deploy DANE without also deploying anything else, except DNSSEC. Keep it light 🦋

Minimal Options: Ideally, DANE SHOULD have only one operating mode. Practically, DANE SHOULD have as few operating modes as possible. Less is more, periodt 💅

Wildcards: The mechanism for distributing DANE information SHOULD allow the use of DNS wildcard labels (*) for setting DANE information for all names within a wildcard expansion. Wildcard energy 🌟

Redirection: The mechanism for distributing DANE information SHOULD work when the application service name is the result of following a DNS redirection chain (e.g., via CNAME or DNAME). Redirects don't get in the way 🧚

5. Acknowledgements 💜

Huge thanks to Eric Rescorla for the first version of the use cases, Zack Weinberg and Phillip Hallam-Baker for contributing other requirements, and the whole DANE working group for helpful comments on the mailing list 🫶🌸

6. Security Considerations 🔐

Okay, this part is serious, so pay attention 🙈 The main focus of this document is making TLS authentication better by using the DNS. What that does is give DNS operators a bigger role in authentication, either instead of or alongside traditional third parties like commercial certificate authorities. That's a huge shift in who holds the power 😭 The specific security implications of each use case are covered in their own sections above, so go check those out too 💀

7. References 📚

7.1. Normative References

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "DNS Security Introduction and Requirements",
           RFC 4033, 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.

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

7.2. Informative References

[RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
           RFC 2595, June 1999.

[RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
           Transport Layer Security", RFC 3207, February 2002.

[RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
           A., Peterson, J., Sparks, R., Handley, M., and E.
           Schooler, "SIP: Session Initiation Protocol", RFC 3261,
           June 2002.

[RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
           Protocol (XMPP): Core", RFC 6120, March 2011.

Author's Address 📮

Richard Barnes
BBN Technologies
9861 Broken Land Parkway
Columbia, MD  21046
US

Phone: +1 410 290 6169
EMail: rbarnes@bbn.com