idnits 2.17.00 (12 Aug 2021) /tmp/idnits46423/draft-proxied-svcb-headers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 February 2021) is 449 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-dnsop-svcb-https-02 == Outdated reference: A later version (-12) exists of draft-ietf-masque-connect-udp-03 == Outdated reference: A later version (-14) exists of draft-ietf-tls-esni-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft Apple, Inc. 4 Intended status: Standards Track 19 February 2021 5 Expires: 23 August 2021 7 HTTP Header Fields for Proxied SVCB Metadata 8 draft-proxied-svcb-headers-00 10 Abstract 12 This document defines HTTP header fields for the passing Service 13 Binding (SVCB) DNS metadata in HTTP responses. 15 Discussion Venues 17 This note is to be removed before publishing as an RFC. 19 Source for this draft and an issue tracker can be found at 20 https://github.com/tfpauly/privacy-proxy. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 23 August 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 57 2. SVCB Request Header Field . . . . . . . . . . . . . . . . . . 3 58 3. SVCB Response Header Fields . . . . . . . . . . . . . . . . . 3 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 CONNECT [RFC7231] and CONNECT-UDP [I-D.ietf-masque-connect-udp] are 68 HTTP methods that clients may use to establish TCP or UDP flows to 69 target servers. Once proxy servers establish these flows, proxy 70 servers treat allocated flows as opaque byte or datagram streams 71 respectively. Clients specify the target in authority-form 72 (Section 5.3 of [RFC7230]), including the name or IP address of the 73 server along with a port number. When using a name instead of an IP 74 address, the proxy server locally resolves the name to an IPv4 or 75 IPv6 address with A or AAAA queries. The client does not see these A 76 or AAAA answers, as they are only relevant to the proxy in 77 establishing a connection to the target. 79 In some circumstances, some DNS metadata may be useful to clients. 80 This is especially true for information contained in Service Binding 81 (SVCB or HTTPS) records [I-D.ietf-dnsop-svcb-https]. These records 82 can influence client behavior even when clients are not directly 83 interacting with target IP addresses. The records can be used to 84 determine which application-level protocols are supported by an 85 endpoint. These records also can include a TLS Encrypted Client 86 Hello [I-D.ietf-tls-esni] configuration, which can be used in 87 protecting the end-to-end TLS handshake. 89 This document specifies HTTP header fields that proxy servers may use 90 to relay information retrieved from SVCB records from proxy servers 91 to clients when using CONNECT or CONNECT-UDP. 93 1.1. Requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 2. SVCB Request Header Field 103 Clients can request SVCB parameters with the Structured Header 104 [RFC8941] "DNS-SVCB-Keys". Its value MUST be an sf-list whose 105 members are sf-integer items that MUST NOT contain parameters. Its 106 ABNF is: 108 DNS-SVCB-Keys = sf-list 110 Each list member corresponds to the numeric version of an 111 SvcParamKey. 113 For example, a client wanting to receive ALPN and ECH Config 114 parameters would send a request for 1 (alpn) and 5 (echconfig): 116 HEADERS 117 :method = CONNECT 118 :authority = svc.example.com:443 119 dns-svcb-keys = 1, 5 121 3. SVCB Response Header Fields 123 A proxy server that receives a request with "DNS-SVCB-Keys" MAY 124 respond with the Structured Header "DNS-SVCB-Params" response header 125 fields. The value of "DNS-SVCB-Params" MUST be an sf-list whose 126 members are sf-string, each of which MUST contain parameters. 128 DNS-SVCB-Params = sf-list 130 Each list member is an sf-string that represents the TargetName of a 131 single received SVCB or HTTPS record. The Parameters associated with 132 each list member correspond to the SvcParam key-value pairs for that 133 record, the priority of the record, and the TTL of the record. 135 The priority of the record MUST be a parameter with the key 136 "priority", and a value as an sf-integer. Alias forms, with priority 137 0, MUST NOT be included. 139 The TTL of the record MUST be a parameter with the key "ttl", and a 140 value as an sf-integer. 142 Each SvcParam that matches a key requested by the client is a 143 parameters with a key that is the character "p" followed by the 144 numeric version of the SvcParamKey. For example, the ALPN 145 SvcParamKey, with the numeric value 1, would have a parameter key 146 "p1". The value of each parameter MUST be an sf-binary item that 147 contains the bytes of the SvcParamValue. 149 Proxy servers MUST NOT include the "DNS-SVCB-Params" response header 150 field if the corresponding request did not include a "DNS-SVCB-Keys". 151 Servers MAY include specific SvcParamKey values that were not 152 requested. Specifically, servers SHOULD include the "mandatory" 153 parameter if present, which would be presented as "p0", along with 154 any parameters that are defined as mandatory for that record. 156 As an example, assume that the server received the following 157 "svc.example.com" SVCB records: 159 svc.example.com. 3600 IN HTTPS 1 svc2.example.com. alpn=h2,h3 echconfig="123..." 160 svc.example.com. 3600 IN HTTPS 2 . alpn=h2 echconfig="abc..." 162 A successful CONNECT response would include the following headers, if 163 the client requested both "alpn" and "echconfig": 165 HEADERS 166 :method = CONNECT 167 :status = 200 168 dns-svcb-params = "svc2.example.com.";priority=1;ttl=3600;p1=:aDIsaDM=:;p5=:MTIzLi4u:, 169 "svc.example.com.";priority=2;ttl=3600;p1=:aDI=:;p5=:YWJjLi4u: 171 4. IANA Considerations 173 4.1. HTTP Headers 175 This document registers the "DNS-SVCB-Keys" and "DNS-SVCB-Params", 176 headers in the "Permanent Message Header Field Names" 177 . 179 +----------------------+----------+--------+---------------+ 180 | Header Field Name | Protocol | Status | Reference | 181 +----------------------+----------+--------+---------------+ 182 | DNS-SVCB-Keys | http | exp | This document | 183 +----------------------+----------+--------+---------------+ 184 | DNS-SVCB-Params | http | exp | This document | 185 +----------------------+----------+--------+---------------+ 187 5. Security Considerations 189 The "DNS-SVCB-Params" header in Section 3 does not include any DNSSEC 190 information. Clients that depend on the contents of the SVCB record 191 being DNSSEC-validated MUST NOT use this metadata without otherwise 192 fetching the record and its corresponding RRSIG record and locally 193 verifying its contents. 195 6. Normative References 197 [I-D.ietf-dnsop-svcb-https] 198 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 199 and parameter specification via the DNS (DNS SVCB and 200 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 201 dnsop-svcb-https-02, 2 November 2020, 202 . 205 [I-D.ietf-masque-connect-udp] 206 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 207 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 208 03, 5 January 2021, . 211 [I-D.ietf-tls-esni] 212 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 213 Encrypted Client Hello", Work in Progress, Internet-Draft, 214 draft-ietf-tls-esni-09, 16 December 2020, 215 . 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, 220 DOI 10.17487/RFC2119, March 1997, 221 . 223 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 224 Protocol (HTTP/1.1): Message Syntax and Routing", 225 RFC 7230, DOI 10.17487/RFC7230, June 2014, 226 . 228 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 229 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 230 DOI 10.17487/RFC7231, June 2014, 231 . 233 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 234 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 235 May 2017, . 237 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 238 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 239 . 241 Author's Address 243 Tommy Pauly 244 Apple, Inc. 246 Email: tpauly@apple.com