Internet Engineering Task Force Initials Muralip. Palanisamy, Ed. Internet-Draft AppViewX Inc Intended status: Informational Initials AnandD. Deshmukh, Ed. Expires: 9 December 2024 Bank of New York Mellon 7 June 2024 Certificate Trust Anchor Management using DNS draft-rfcxml-trust-anchor-management-using-dns-00 Abstract Certificate Trust Stores are the foundation of trust, with Quantum threat looming updating trust anchors is a challenge for IOT and distributed devices. Using DNS as a foundation for trust since every communication uses DNS and DNSSEC to securely verify the domain resolution we use DNS to securely publish the Trust Store Content or update the trust anchors to be used to validate the TLS connection. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Palanisamy & Deshmukh Expires 9 December 2024 [Page 1] Internet-Draft Abbreviated Title June 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. 2. Problem Statement . . . . . . . . . . . . . . . . . . 3 2. 3. DNS CERT Records . . . . . . . . . . . . . . . . . . . . 4 3. 4. TLS Server Validation with DNS CERT Certificates . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Domain Name System (DNS) is essential for the proper functioning of the internet, serving as the foundational pillar of trust for every digital transaction. Each web page visited, email sent, and digital communication relies on DNS to translate human-friendly names into destination addresses. Certificates are another form of trust used to validate and verify endpoints like websites and servers, leveraging Public Key Cryptography or Public Key Infrastructure (PKI). Public keys or Certificate Authorities (CAs) are embedded in device trust stores or browsers to verify endpoint certificates deployed on servers or websites. In a zero trust environment or with a short lived certificate authority there is a need to dynamically provide or update trust stores or even present certificate used to validate the domains. For this DNS can be used as a foundation of trust by leveraging Domain Name System (DNS) CERT records which are DNSSEC signed to be used to validate the domain. Section 3 specifies a CERT resource record (RR) for the storage of certificates in the Domain Name System (DNS) as detailed in RFC 4398. Section 4 explains how Server Trust can be valdiated using Certificate from DNS. Palanisamy & Deshmukh Expires 9 December 2024 [Page 2] Internet-Draft Abbreviated Title June 2024 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. 2. Problem Statement Trust anchors are used to support many application scenarios. Most Internet browsers and email clients use trust anchors when authenticating Transport Layer Security (TLS) sessions by validating a certification path to a server's certificate. Trust anchors that support these applications are typically installed as part of the operating system (OS) or application,installed using an enterprise configuration management system, or installed directly by an OS or application user. Trust anchors are typically stored in application- specific or OS-specific trust anchor stores.Often, a single machine may have a number of different trust anchor stores that may not be synchronized.Reviewing the contents of a particular trust anchor store typically involves use of a proprietary tool that interacts with a particular type of trust store. The presence of a trust anchor in a particular store often conveys implicit authorization to validate signatures for any contexts from which the store is accessed. If the store containing this TA is used by multiple applications that serve different purposes, the same key may be used (inappropriately) to validate other types of objects such as certificates or Online Certificate Status Protocol (OCSP) responses. Trust anchors are often represented as self-signed certificates,which provide no useful means of establishing the validity of the information contained in the certificate.Confidence in the integrity of a trust anchor is typically established through out-of-band means, often by checking the "fingerprint" (one-way hash) of the self-signed certificate with an authoritative source. Routine trust anchor rekey operations typically require similar out-of-band checks, though in- band rekey of a trust anchor is supported by the Certificate Management Protocol (CMP) RFC4210. Ideally, only the initial set of trust anchors are installed in a particular trust anchor store should require out-of-band verification, particularly when the costs of performing out-of-band checks commensurate with the security requirements of applications using the trust anchor store are high. Despite the prevalent use of trust anchors, there is neither a standard means for discovering the set of trust anchors installed in a particular trust anchor store nor a standard means of managing those trust anchors. The remainder of this document describes requirements for a solution to this problem using DNS and DNSSEC along with some security considerations.This specification is improve Palanisamy & Deshmukh Expires 9 December 2024 [Page 3] Internet-Draft Abbreviated Title June 2024 security and zero trust by improving access to public keys for end- to-end Transport Layer Security(TLS) communication. This document defines a unique way of using exsiting IETF standard to pass the public key using DNS CERT records that can be used to validate TLS connections. 2.1 Functional Requirement A general-purpose solution for the management of trust anchors MUST be common transport in order to apply to a range of device communications environments. It MUST work in session-oriented environments in a pull distribution model.It should provide integrity and data origin authentication for TA transactions MUST be provided at the application layer.Confidentiality MAY not be needed for such transactions since it is a public key information. 2.2 Solution Approach Using DNS as the foundation of trust Using DNS as the foundation of trust, explicit trust or Zero Trust is possible where the DNS domain owner publishes the Public Certificate used to sign their website or server certificate. With DNSSEC and using DNS CERT records, the owner can authoritatively validate and publish a CA issued public certificate with integrity and verifiable legitimacy.This enables verification of the DNS domain to the actual server. In turn, application level verification of the certificate is directly from the DNS name owners and ensures that the DNS names have the correct CAs verifying the certificates. Trust Anchor Management TLS clients can look up DNS for the domain CERT DNS record (RFC 4398) to retrieve the Trust Anchor that can be updated with a short Time-to-Live (TTL) value enabling short lived certificate authority support. The complete list of trusted certificates can be published with multiple CERT records based on application or enterprise top level domain. Publishing Certificate Authority Public Keys enables explicit trust with agility to switch and reduce Certificate Authority and Certificate validity aimed at reducing future Quantum computing threats and enabling Zero Trust. 2. 3. DNS CERT Records RFC 4398 details CERT resource records structure. With the specification defined the Servers public key or possibly root certificate to validate the chain can be publised on the same domains name with CERT records. For example example.com. can have an A record and a CERT record and the CERT record can have the certificate used to validate the domain. DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 9364 is a pre-requsite must have for this since the certificate is used to validate the domains. DNSSEC uses digital signatures based on public key cryptography to sign responses by the domain owner. It serves two primary functions: Data Origin Authentication: This allows resolvers/ clients to cryptographically verify that the responses actually originate from the owner of the DNS name. Data Integrity Protection: This enables resolvers/clients to verify that the data has not been Palanisamy & Deshmukh Expires 9 December 2024 [Page 4] Internet-Draft Abbreviated Title June 2024 altered during transit. Example: example.com. 296 IN CERT 0 0 0 ( M IIB8zCCAZmgAwIBAgITQMvCiTnXkcxee5eiUrzKJIna8TAKBggqhkjOPQQD+MREwDwYDV QQKEwhBcHB2aWV3eDELMAkGA1UECxMCSVQxHDAaBgNVBAMTE0lULUFWWC1Sb290LUdDQV MtRUMwHhcNMjMwNTExMDc1MDIyWhcNMzMwNTA4MDc1MDI+MREwDwYDVQQKEwhBcHB2aWV 3eDELMAkGA1UECxMCSVQxHDAaBgNVBAMTE0lULUFWWC1Sb290LUdDQVMtRUMwWTATBgcq hkjOPQIBBggqhkjOPQMBBwNCAATkccapehNjCA3Hgjj+XLxFQayMtDUUHi3+fO5OgGa36 llwn6QPWKhXxNNK+x+Y3QrDWPq0IK8j0jopoBo3YwdDAOBgNVHQ8BAf8EBAMCAQYwDwYD VR0TAQ/BAUwAw/zAdBgNVHQ4EFgQUNPcUdSNHNjLULpkUMEJ4sUjbtIwHwYDVR0jBBgwF oAUNPcUdSNHNjLULpkUME4J4sUjbtIwEQYDVR0gBAowCDAGBgRVHSAAMAoGCCqGSM49BA MCA0gAMEUCIQCZ6ZgBMr+ir2Fzu192+RFMuLqV973KaiDvSOVuf2gIgXkcYJB79bIqBvz JFssuAanEBLhGF+O9grlxPNNeLdU= ) example.com. 296 IN RRSIG CERT 13 3 300 ( 20240522233005 20240520213005 34505 example.com. ZttZh6XV3HbFY WyztXOQrznMlphJzlmuFmObE1JqXCmh14MC69bxxsjsE5fX6kGkmTn4gaNR01kLg+z1Jl 7A== ) the same can be used to validate the connection. 3. 4. TLS Server Validation with DNS CERT Certificates Digital signatures are used in many applications. For digital signatures to provide integrity and authentication, the public key used to verify the digital signature must be "trusted", i.e.,accepted by a relying party (RP) as appropriate for use in the given context. A public key used to verify a signature must be configured as a trust anchor (TA) or contained in a certificate that can be transitively verified by a certification path terminating at a trust anchor. A trust anchor is a public key and associated data used by a relying party to validate a signature on a signed object where the object is either: o a public key certificate that begins a certification path terminated by a signature certificate or encryption certificate o an object, other than a public key certificate or certificate revocation list (CRL), that cannot be validated via use of a certification path Trust anchors have only local significance, i.e., each RP is configured with a set of trust anchors, either by the RP or by an entity that manages TAs in the context in which the RP operates. The associated data defines the scope of a trust anchor by imposing constraints on the signatures that the trust anchor may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types. All applications that rely upon digital signatures rely upon some means of managing one or more sets of trust anchors. Each set of trust anchors is referred to in this document as a trust anchor store. Trust Anchor: A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in Palanisamy & Deshmukh Expires 9 December 2024 [Page 5] Internet-Draft Abbreviated Title June 2024 the associated data for the trust anchor. In this new approach during the TLS communication while the client can looks up DNS name of the target server for IP address it can also lookup for a CERT record which is DNSSEC validated and use the CERT record to validate the integrity and authenticate the server if its appropriate. This use case is primarily useful in case of internet facing Internet of Things Deployments like Smart Meters, Connected Cars where Crypto Agility is a requirement due to the threat of Quantum Computers. These can be implemented by updating the TLS clients and DNS clients with updated steps to look up for the right certificates. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations This document should not affect the security of the Internet. It can be extended to all TLS connections if the browsers accept the updated trust anchors. DNSSEC keys have to be updated with quantum safe algorithms for this to be considered quantum safe communication 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Acknowledgements This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. It uses contents from RFC 6024 Trust Anchor Management, RFC 4398 Storing Certificates in DNS Contributors Thanks to all of the contributors. Thanks to Claudine Ramocan for the solution discussions Thanks to Ganesh Gopalan and Asif Karel for validating the solution Thanks to Marin Cosmin Stefan for reviewing the solution Palanisamy & Deshmukh Expires 9 December 2024 [Page 6] Internet-Draft Abbreviated Title June 2024 Authors' Addresses Muralidharan Palanisamy (editor) AppViewX Inc 222 Broadway New York, NY 10038 United States of America Phone: Phone 2016063304 Email: muralida@gmail.com URI: URI www.appviewx.com. Anand Deshmukh (editor) Bank of New York Mellon 240 Greenwitch Street New York, NY 10038 United States of America Email: anand2031@icloud.com URI: URI Palanisamy & Deshmukh Expires 9 December 2024 [Page 7]