Internet DRAFT - draft-steckbeck-ua-conn-sec
draft-steckbeck-ua-conn-sec
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,
<https://www.rfc-editor.org/rfc/rfc1464>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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
