Network Working Group D. Steckbeck Internet-Draft Intended Status: Standards Track Category: Experimental March 2023 User Agent Connection Security draft-steckbeck-ua-conn-sec-00.txt Abstract The user agent to server transaction has many attack surfaces which have been defended by various recommendations such as Content Security Policy. An attack vector that is currently exploited is the open connection policy to first, second- and third-party resources. A breach of the origin website or other connected resource could require the client to load resources from a malicious network. This document provides a framework which allows authors to publish authorized connectable second- and third-party resources that a user agent should or must follow depending on configuration of that user agent. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 13 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 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 1.1 Terminology 1.2 Applicability 2 Conventions used in this document 2.1 DNS Entries published 2.1.1 Single site and domain example 2.1.2 Multiple sites and domain example 2.1.3 Wildcards 3 Security Considerations 4 IANA Considerations 5 References 5.1 Normative References 6 Acknowledgments 1 Introduction The traditional website model for distributing information has been one of open resource connections. Website authors are in control as to how the published resource connections draw upon other resources. This model leaves end-users and administrators who require higher connection security to either trust the site author implicitly or profile a website and provide connection security through other means. Establishing a trust model where all connections are approved by both parties, is an additional step in providing a model where users and administrators can be assured the website they are using is making author-verified connections to second- and third-parties. This document covers an implementation for website authors to indicate a validation method of second- and third-party resources and a strict or compatible model for browser owners to enforce depending on their security requirements. 1.1 Terminology 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. The term "researcher" corresponds to the terms "finder" and "reporter" in [ISO.29147.2018] and [CERT.CVD]. The term "organization" corresponds to the term "vendor" in [ISO.29147.2018] and [CERT.CVD]. 1.2 Applicability This document covers a method of actions user-agents and website authors should implement to enhance security. 2 Conventions used in this document First-party connections are those created to the same host listed in the URL. Second-party connections are those created to other hosts using the same top level domain. Third-party connections are those to a host with a different host listed in the URL. 2.1 DNS Entries published The DNS entry is a TXT record which was proposed in [RFC1464]. The format of the record begins with uacs=1; and an optional host= identifier, if the domain serves multiple hostnames which require user-agent connection security. Every semi-colon separated entry after it must be a [RFC1123] and [RFC4343] formatted host identifier. Length 2.1.1 Single site and domain example An example record for a single website hosted from a domain: uacs=1;host.example1.com;*.example2.com;zzz.example-cloud-network.net 2.1.2 Multiple sites and domain example If a domain serves multiple websites requiring user-agent connection security, these records MUST be broken up into separate TXT records with an identifying host tag: uacs=1;host=website1.example.com;host.example1.com;*.example2.com uacs=1;host=website2.example.com;host.example1.com;*.example2.com Hostname entries are separated by semicolons and no spaces. Where characters have case representations, all characters should be in lower case versions. 2.1.3 Wildcards Wildcards are allowed to reduce record sizes and client processing time, for example a website hosted at example1.com can include resources from *.example2.com in order to accommodate changes example2.com may publish to their service. The wildcard MUST be interpreted as meaning 0 or more characters. Caution should be used when using wildcards with services that publish random hostnames for customers since site authors may not intend for data from other customers to be referenced. For example, a content distribution network may create content access URIs such as 123456.example.net for every customer. A wildcard against this network would grant resource load opportunities for any non-related customers of that service. Only one uacs= and one host= are allowed per TXT record. 2.2 User-Agent Requests User-Agents SHOULD include the TXT record request at the time of the DNS request to resolve the host name, should subsequently send the request to retrieve the uacs= TXT record prior to processing any further connection requests other than the initial resource request. 2.3 Caching User-Agents SHOULD follow their normal caching rules for the TXT records request. 2.4 User-Agent Enforcement Modes Compatible, Compliant, Strict 2.4.1 Compatible mode Compatible mode is included as a transition option. This mode indicates the user-agent SHOULD NOT enforce any uacs entries. 2.4.2 Compliant mode Compliant mode indicates the user-agent MUST process and follow the rules identified by a website author. 2.4.3 Strict mode Strict mode indicates the user-agent should not connect to any resources beyond the domain. 2.5 Record Size Published records SHOULD be limited to fit within the 512 octet limit. If not, it could exceed the DNS protocol limit. For further details on the technical details, please see [RFC7208] section 3.4 entitled Record Size and [RFC2181] section 11 entitled Name Syntax. It is RECOMMENDED to follow these directions. 3 Security Considerations 3.1 Sensible initial defaults The initial compatible user agent mode was chosen as a lead in order to provide a path for adoption due to this RFC requiring changes from both website operators and developers of user-agents. 3.2 DNS TXT versus a text file The DNS TXT entry was chosen after working through a model with a plain text file, similar to security.txt or a robots.txt file. After consideration, one of the defensive tactics for UACS is to protect a client against a server compromise attack in which a text file could be replaced by an attacker. Having the approved connections list separate provides an additional layer of defense. 3.3 Misconfigurations It is possible to configure the connection host entries too inclusively thereby allowing connections to unintended hosts and degrading the security posture this RFC is proposing. 3.4 Profiling A profile-building model of security is prone to functional deferred deprecation upon website updates. For organizations managing security profiles, not every security administrator is willing to trust every website vendor implicitly, and not every website vendor openly discloses every third-party resource connection. Attacks that leverage injectionable payloads from second- and third-party connections require an open connection to an attacker-controlled resource. Limiting attacks with connection restrictions such as this RFC reduces the available options an attacker may use and improves the security posture of the user agent. 4 IANA Considerations This draft does not require any IANA action. 5 References 5.1 Normative References [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", RFC 1123, October 1989 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, DOI 10.17487/RFC1464, May 1993, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R., "Clarifications to the DNS Specification", RFC 2181, July 1997 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6 Acknowledgments The author would like to thank Steven Hart, Michael J. Cataletto, Yulia Slesavara and the many other team members who contributed suggestions and edits to help complete this document. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses David Steckbeck Email: dsteckbeck@gatech.edu