< draft-nygren-httpbis-httpssvc-02.txt   draft-nygren-httpbis-httpssvc-03.txt >
HTTP Working Group B. Schwartz HTTP Working Group B. Schwartz
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Bishop Intended status: Standards Track M. Bishop
Expires: January 9, 2020 E. Nygren Expires: January 9, 2020 E. Nygren
Akamai Technologies Akamai Technologies
July 8, 2019 July 8, 2019
HTTPSSVC service location and parameter specification via the DNS (DNS HTTPSSVC service location and parameter specification via the DNS (DNS
HTTPSSVC) HTTPSSVC)
draft-nygren-httpbis-httpssvc-02 draft-nygren-httpbis-httpssvc-03
Abstract Abstract
This document specifies an "HTTPSSVC" DNS resource record type to This document specifies an "HTTPSSVC" DNS resource record type to
facilitate the lookup of information needed to make connections for facilitate the lookup of information needed to make connections for
HTTPS URIs. The HTTPSSVC DNS RR mechanism allows an HTTPS origin HTTPS URIs. The HTTPSSVC DNS RR mechanism allows an HTTPS origin
hostname to be served from multiple network services, each with hostname to be served from multiple network services, each with
associated parameters (such as transport protocol and keying material associated parameters (such as transport protocol and keying material
for encrypting TLS SNI). It also provides a solution for the for encrypting TLS SNI). It also provides a solution for the
inability of the DNS to allow a CNAME to be placed at the apex of a inability of the DNS to allow a CNAME to be placed at the apex of a
skipping to change at page 13, line 29 skipping to change at page 13, line 29
1. Replace the "http" scheme with "https". 1. Replace the "http" scheme with "https".
2. If the "http" URL explicitly specifies port 80, specify port 443. 2. If the "http" URL explicitly specifies port 80, specify port 443.
3. Do not alter any other aspect of the URL. 3. Do not alter any other aspect of the URL.
This construction is equivalent to Section 8.3 of [HSTS] , point 5. This construction is equivalent to Section 8.3 of [HSTS] , point 5.
If an HTTPSSVC record is present for this "https" URL, the client If an HTTPSSVC record is present for this "https" URL, the client
should treat this as the equivalent of receiving an HTTP "302 Found" should treat this as the equivalent of receiving an HTTP "307
redirect to the "https" URL. Because HTTPSSVC is received over an Temporary Redirect" redirect to the "https" URL. Because HTTPSSVC is
often insecure channel (DNS), clients MUST NOT place any more trust received over an often insecure channel (DNS), clients MUST NOT place
in this signal than if they had received a 302 redirect over any more trust in this signal than if they had received a 307
cleartext HTTP. redirect over cleartext HTTP.
If the HTTPSSVC query results in a SERVFAIL error, and the connection If the HTTPSSVC query results in a SERVFAIL error, and the connection
between the client and the recursive resolver is cryptographically between the client and the recursive resolver is cryptographically
protected (e.g. using TLS [RFC7858] or HTTPS [RFC8484]), the client protected (e.g. using TLS [RFC7858] or HTTPS [RFC8484]), the client
SHOULD abandon the connection attempt and display an error message. SHOULD abandon the connection attempt and display an error message.
A SERVFAIL error can occur if the domain is DNSSEC-signed, the A SERVFAIL error can occur if the domain is DNSSEC-signed, the
recursive resolver is DNSSEC-validating, and an active attacker recursive resolver is DNSSEC-validating, and an active attacker
between the recursive resolver and the authoritative DNS server is between the recursive resolver and the authoritative DNS server is
attempting to prevent the upgrade to HTTPS. attempting to prevent the upgrade to HTTPS.
skipping to change at page 15, line 51 skipping to change at page 15, line 51
Alternative A is reliably accessible but does not support ESNI. Alternative A is reliably accessible but does not support ESNI.
Alternative B supports ESNI but is not reliably accessible. The Alternative B supports ESNI but is not reliably accessible. The
server operator could include a full esnikeys value in Alternative B, server operator could include a full esnikeys value in Alternative B,
and mark Alternative A with esnikeys="" to indicate that fallback and mark Alternative A with esnikeys="" to indicate that fallback
from B to A is allowed. from B to A is allowed.
7.2. Interaction with other standards 7.2. Interaction with other standards
The purpose of this standard is to reduce connection latency and The purpose of this standard is to reduce connection latency and
improve user privacy. Server operators implementing this standard improve user privacy. Server operators implementing this standard
SHOULD also implement TLS 1.3 [I-D.ietf-tls-tls13] and OCSP Stapling SHOULD also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066],
both of which confer substantial performance and privacy benefits
[RFC6066], both of which confer substantial performance and privacy when used in combination with HTTPSSVC records.
benefits when used in combination with HTTPSSVC records.
To realize the greatest privacy benefits, this proposal is intended To realize the greatest privacy benefits, this proposal is intended
for use with a privacy-preserving DNS transport (like DNS over TLS for use with a privacy-preserving DNS transport (like DNS over TLS
[RFC7858] or DNS over HTTPS [RFC8484]). However, performance [RFC7858] or DNS over HTTPS [RFC8484]). However, performance
improvements, and some modest privacy improvements, are possible improvements, and some modest privacy improvements, are possible
without the use of those standards. without the use of those standards.
This RRType could be extended to support schemes other than "https". This RRType could be extended to support schemes other than "https".
Any such scheme MUST have an entry under the HTTPSSVC RRType in the Any such scheme MUST have an entry under the HTTPSSVC RRType in the
IANA DNS Underscore Global Scoped Entry Registry [Attrleaf] The IANA DNS Underscore Global Scoped Entry Registry [Attrleaf] The
skipping to change at page 18, line 20 skipping to change at page 18, line 20
[HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>. <https://www.rfc-editor.org/info/rfc6797>.
[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-20 (work in progress), (HTTP/3)", draft-ietf-quic-http-20 (work in progress),
April 2019. April 2019.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
skipping to change at page 19, line 19 skipping to change at page 19, line 14
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
11.2. Informative References 11.2. Informative References
[DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
skipping to change at page 23, line 17 skipping to change at page 23, line 17
others all have their own variations here. others all have their own variations here.
C.6. Whether to include Weight C.6. Whether to include Weight
Some other similar mechanisms such as SRV have a weight in-addition Some other similar mechanisms such as SRV have a weight in-addition
to priority. That is excluded here for simplicity. It could always to priority. That is excluded here for simplicity. It could always
be added as an optional Alt-Svc attribute. be added as an optional Alt-Svc attribute.
Appendix D. Change history Appendix D. Change history
o draft-nygren-httpbis-httpssvc-03
* Change redirect type for HSTS-style behavior from 302 to 307 to
reduce ambiguities.
o draft-nygren-httpbis-httpssvc-02 o draft-nygren-httpbis-httpssvc-02
* Remove the redundant length fields from the wire format. * Remove the redundant length fields from the wire format.
* Define aSvcDomainName of "." for SvcRecordType=1 as being the * Define a SvcDomainName of "." for SvcRecordType=1 as being the
HTTPSSVC RRNAME. HTTPSSVC RRNAME.
* Replace "hq" with "h3". * Replace "hq" with "h3".
o draft-nygren-httpbis-httpssvc-01 o draft-nygren-httpbis-httpssvc-01
* Fixes of record name. Replace references to "HTTPSVC" with * Fixes of record name. Replace references to "HTTPSVC" with
"HTTPSSVC". "HTTPSSVC".
o draft-nygren-httpbis-httpssvc-00 o draft-nygren-httpbis-httpssvc-00
 End of changes. 7 change blocks. 
16 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/