인터넷 엔지니어링 태스크 포스 (IETF)

M. Nottingham

Request for Comments: 8336

E. Nygren

카테고리: 표준 트랙

Akamai

ISSN: 2070-1721

2018년 3월

ORIGIN HTTP/2 프레임

요약

이 문서는 주어진 연결에서 어떤 오리진이 사용 가능한지를 나타내기 위한 HTTP/2의 ORIGIN 프레임을 명세합니다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물입니다. 이 문서는 IETF 커뮤니티의 합의를 나타냅니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 운영 그룹(IESG)의 출판 승인을 받았습니다. 인터넷 표준에 대한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.

이 문서의 현재 상태, 정오표 및 이에 대한 피드백 제공 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc8336에서 확인할 수 있습니다.

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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 소개
- 1.1. 표기 규약
2. The ORIGIN HTTP/2 Frame
- 2.1. 구문
- 2.2. ORIGIN 프레임 처리
- 2.3. The Origin Set
- 2.4. Authority, Push, and Coalescing with ORIGIN
3. IANA 고려사항
4. 보안 고려사항
5. 참조
- 5.1. 규범 참조
- 5.2. 정보 참조
Appendix A. 비규범 처리 알고리즘
Appendix B. 서버 운영 고려사항
저자 주소

1. 소개

HTTP/2 [RFC7540]는 일부 조건이 충족되는 경우 클라이언트가 서로 다른 오리진([RFC6454])을 동일한 연결로 합쳐서(coalesce) 사용할 수 있게 합니다. 그러나 어떤 경우에는 연결이 합쳐진 오리진에 대해 사용 불가능할 수 있어, 421 (Misdirected Request) 상태 코드([RFC7540], 섹션 9.1.2)가 정의되었습니다.

이와 같이 상태 코드를 사용하는 것은 클라이언트가 잘못된 대상의 요청에서 복구할 수 있게 해주지만, 지연(latency)이 추가되는 대가를 수반합니다. 이를 해결하기 위해 본 명세는 서버가 연결에서 어떤 오리진에 대해 연결이 사용 가능함을 표시할 수 있도록 하는 새로운 HTTP/2 프레임 타입 "ORIGIN"을 정의합니다.

추가로 경험적으로 HTTP/2가 DNS와 서버 인증서 둘 다를 사용해 서버 권한을 확립하도록 요구하는 것은 부담이 큰 것으로 나타났습니다. 이 명세는 ORIGIN 프레임이 사용되는 경우 DNS 확인 요구사항을 완화합니다. 이렇게 하면 일부 DNS 조회와 관련된 지연을 제거하는 등 추가적인 이점이 있습니다.

1.1. 표기 규약

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"이라는 핵심 단어들은 대문자로만 나타날 때에 한하여 BCP 14 (RFC2119, RFC8174)에 설명된 대로 해석됩니다.

2. The ORIGIN HTTP/2 Frame

이 문서는 ORIGIN이라고 불리는 새로운 HTTP/2 프레임 타입([RFC7540], 섹션 4)을 정의합니다. 이 프레임은 서버가 해당 연결 내에서 클라이언트가 Origin Set(섹션 2.3)의 구성원으로 간주하기를 원하는 오리진([RFC6454])을 표시할 수 있게 합니다.

2.1. 구문

ORIGIN 프레임 타입은 0xc(십진수 12)이며 하나 이상의 Origin-Entry 필드를 포함할 수 있습니다.

+-------------------------------+-------------------------------+
|         Origin-Entry (*)                                    ...
+-------------------------------+-------------------------------+

Origin-Entry는 길이로 구분된 문자열입니다:

+-------------------------------+-------------------------------+
|         Origin-Len (16)       | ASCII-Origin?               ...
+-------------------------------+-------------------------------+

구체적으로는:

Origin-Len:: ASCII-Origin 필드의 길이를 옥텟 단위로 나타내는 부호 없는 16비트 정수입니다.
Origin:: 보낸이가 이 연결이 권한을 가지거나 권한을 가질 수 있다고 주장하는 오리진의 ASCII 직렬화를 포함하는 선택적 문자 시퀀스([RFC6454], 섹션 6.2)입니다.

ORIGIN 프레임은 플래그를 정의하지 않습니다. 그러나 향후 이 명세의 업데이트는 플래그를 정의할 수 있습니다. 자세한 내용은 섹션 2.2를 참조하십시오.

2.2. ORIGIN 프레임 처리

ORIGIN 프레임은 HTTP/2에 대한 비중요 확장입니다. 이 프레임을 지원하지 않는 엔드포인트는 수신 시 이를 안전하게 무시할 수 있습니다.

구현된 클라이언트가 수신하면, 이 프레임은 Origin Set(섹션 2.3)을 초기화하고 조작하는 데 사용되어 클라이언트가 오리진 서버의 권한을 확립하는 방식을 변경합니다(자세한 내용은 섹션 2.4 참조).

ORIGIN 프레임은 반드시 stream 0에서 전송되어야 합니다; 다른 스트림에서의 ORIGIN 프레임은 유효하지 않으며 무시되어야 합니다.

마찬가지로 ORIGIN 프레임은 "h2" 프로토콜 식별자를 사용하는 연결에서만 유효하며, 프로토콜 정의에 의해 명시적으로 지명된 경우를 제외하고는 "h2c" 프로토콜 식별자를 사용하는 연결에서 수신되면 무시되어야 합니다.

이 명세는 ORIGIN 프레임에 대한 플래그를 정의하지 않지만, 향후 IETF 합의에 따른 업데이트가 의미를 변경하기 위해 플래그를 사용할 수 있습니다. 처음 네 플래그(0x1, 0x2, 0x4, 0x8)는 하위 호환성을 깨는 변경을 위해 예약되어 있으므로, 이들 중 하나라도 설정된 경우 해당 플래그의 의미를 이해하지 못하는 이 명세 준수 클라이언트는 해당 ORIGIN 프레임을 무시해야 합니다. 나머지 플래그는 하위 호환성 있는 변경을 위해 예약되어 있으며 이 명세에 준수하는 클라이언트의 처리에는 영향을 주지 않습니다.

ORIGIN 프레임은 연결의 속성(property)을 설명하므로 홉 단위로 처리됩니다. 중간 장치는 ORIGIN 프레임을 전달해서는 안 됩니다. 프록시 사용으로 구성된 클라이언트는 프록시로부터 수신한 ORIGIN 프레임을 무시해야 합니다.

프레임 페이로드의 각 ASCII-Origin 필드는 오리진의 ASCII 직렬화로 파싱되어야 합니다([RFC6454], 섹션 6.2). 파싱에 실패하면 해당 필드는 무시되어야 합니다.

ORIGIN 프레임은 와일드카드 이름(예: "*.example.com")을 Origin-Entry에서 지원하지 않는다는 점에 유의하십시오. 결과적으로 와일드카드 인증서가 사용되는 경우 ORIGIN을 전송하면 클라이언트가 ORIGIN을 이해할 때 명시적으로 나열되지 않은 오리진은 효과적으로 사용 불가능해집니다.

ORIGIN 프레임을 처리하는 예시 알고리즘은 부록 A를 참조하십시오.

2.3. The Origin Set

주어진 연결에서 사용될 수 있는 오리진들의 집합(참조: [RFC6454])을 본 명세에서는 Origin Set이라 부릅니다.

기본적으로 연결의 Origin Set은 초기화되지 않은 상태입니다. 초기화되지 않은 Origin Set은 클라이언트가 [RFC7540]의 섹션 9.1.1에 정의된 병합 규칙(coalescing rules)을 적용함을 의미합니다.

ORIGIN 프레임이 처음 수신되어 클라이언트에 의해 성공적으로 처리되면, 해당 연결의 Origin Set은 초기 오리진(initial origin)을 포함하도록 정의됩니다. 초기 오리진은 다음으로 구성됩니다:

Scheme: "https"
Host: Server Name Indication(SNI)([RFC6066], 섹션 3)에 표시된 값(소문자로 변환); SNI가 없으면 연결의 원격 주소(즉, 서버의 IP 주소)
Port: 연결의 원격 포트(즉, 서버의 포트)

그 ORIGIN 프레임(및 이후의 프레임) 내용은 서버가 Origin Set에 새로운 오리진을 점진적으로 추가하도록 허용합니다(자세한 내용은 섹션 2.2 참조).

Origin Set은 또한 421 (Misdirected Request) 응답 상태 코드의 영향을 받습니다(자세한 내용은 [RFC7540], 섹션 9.1.2). 이 상태 코드를 포함한 응답을 수신하면, 구현된 클라이언트는 해당 요청의 오리진의 ASCII 직렬화(참조: [RFC6454], 섹션 6.2)를 생성하고, 존재하면 이를 연결의 Origin Set에서 제거해야 합니다.

Note:: ORIGIN 프레임을 대체 서비스로 초기화된 연결([RFC7838])에 보낼 때, 초기 Origin Set(섹션 2.3)은 적절한 스킴과 호스트 이름을 가진 오리진을 포함하게 됩니다(RFC 7838은 오리진의 호스트 이름을 SNI에 보내도록 지정함). 그러나 초기 Origin Set은 실제로 사용 중인 포트를 사용하여 계산되므로, 의도된 오리진의 포트가 다를 수 있습니다. 이 경우 의도된 오리진은 ORIGIN 프레임에 명시적으로 포함되어야 합니다.; 예를 들어, "https://example.com"에 대한 요청을 하는 클라이언트가 ("h2", "x.example.net", "8443")에 있는 대체 서비스로 안내된 경우, 해당 대체 서비스가 ORIGIN 프레임을 보내면 초기 오리진은 "https://example.com:8443"가 됩니다. 클라이언트는 해당 오리진이 ORIGIN 프레임에 명시적으로 포함되지 않으면 그 대체 서비스를 사용하여 "https://example.com"에 대한 요청을 할 수 없습니다.

2.4. Authority, Push, and Coalescing with ORIGIN

[RFC7540]의 섹션 10.1은 HTTP/1.1의 방식과 마찬가지로 DNS와 제시된 TLS 인증서를 사용하여 연결이 권한을 가지는 오리진 서버들을 확립합니다(참조: [RFC7230]).

또한 [RFC7540]의 섹션 9.1.1은 연결이 권한이 있다면 하나 이상의 오리진 서버에 대해 사용될 수 있음을 명시적으로 허용합니다. 이는 직접 응답과 서버 푸시(참조: [RFC7540], 섹션 8.2.2)에 대해 어떤 응답이 권한 있는 것으로 간주될 수 있는지에 영향을 줍니다. 또한 클라이언트가 일반적으로 어떤 오리진에 대해 권한이 있다고 믿는 연결에서만 요청을 전송하므로 어떤 요청이 연결에서 전송될지도 간접적으로 영향을 받습니다.

Origin Set이 연결에 대해 초기화되면, 이 명세를 구현하는 클라이언트는 이를 연결이 어떤 오리진에 대해 권한을 가지는지 판단하는 데 사용합니다. 구체적으로, 이러한 클라이언트는 Origin Set에 존재하지 않는 오리진에 대해 연결을 권한 있는 것으로 간주해서는 안 되며, 운영상의 이유로 새 연결을 열어야 하는 경우를 제외하고는 연결이 권한을 가지는 Origin Set의 오리진들에 대한 모든 요청에 대해 해당 연결을 사용해야 합니다.

연결이 특정 오리진에 대해 권한을 가지려면 서버가 여전히 적절한 검사를 통과하는 인증서로 인증해야 한다는 점을 유의하십시오. 자세한 내용은 [RFC7540]의 섹션 9.1.1을 참조하십시오. 여기에는 인증서의 subjectAltName 필드에서 호스트가 dNSName 값과 일치하는지 검증하는 것이 포함됩니다(검증 규칙은 [RFC2818]에 정의되어 있으며, 또한 [RFC5280]의 섹션 4.2.1.6을 참조하십시오).

또한 클라이언트는 Origin Set에 있는 오리진에 대한 새로운 요청의 권한을 확립할 때 DNS를 조회하지 않을 수 있습니다; 그러나 그렇게 하는 클라이언트는 섹션 4에 설명된 새로운 위험에 직면하게 됩니다.

ORIGIN은 시간이 지남에 따라 연결이 사용되는 오리진 집합을 변경할 수 있으므로, 클라이언트가 어떤 오리진에 대해 유효한 연결을 둘 이상 열어둘 수 있습니다. 이 경우 클라이언트는 Origin Set이 다른 연결의 Origin Set의 진부분(proper subset)인 연결에서 새 요청을 전송해서는 안 되며, 모든 미완료 요청이 완료되면 해당 연결을 닫아야 합니다.

Origin Set은 서버가 광고하는 어떤 대체 서비스([RFC7838])의 영향도 받지 않습니다. 대체 서비스를 광고하는 것은 서버가 권한이 있는지 여부에 영향을 주지 않습니다.

3. IANA 고려사항

이 명세는 "HTTP/2 Frame Type" 레지스트리에 항목을 추가합니다.

Frame Type: ORIGIN
Code: 0xc
Specification: RFC 8336

4. 보안 고려사항

ORIGIN 프레임의 내용을 무비판적으로 신뢰하는 클라이언트는 다양한 공격에 취약해질 수 있습니다. 완화책은 섹션 2.4를 참조하십시오.

오리진의 권한을 결정할 때 DNS 조회 요구를 완화하면, 유효한 인증서를 가진 공격자는 더 이상 경로 상에 있어야만 트래픽을 자신에게 리디렉트할 필요가 없습니다. 대신 공격자는 사용자가 다른 웹사이트를 방문하도록 유도하기만 하면 그들의 기존 연결로 대상에 대한 연결을 합쳐서(coalesce) 트래픽을 유도할 수 있습니다.

따라서 DNS 조회를 건너뛰기로 선택한 클라이언트는 인증서가 정당하다는 높은 신뢰를 확립하기 위한 대체 수단을 사용해야 합니다. 예를 들어 클라이언트는 인증서가 Certificate Transparency 로그에 포함되었음을 증명받았거나([RFC6962]), 최근의 OCSP 응답([RFC6960])을 통해 인증서가 폐기되지 않았음을 확인한 경우에만 DNS 조회를 건너뛸 수 있습니다. OCSP는 TLS의 "status_request" 확장([RFC6066])을 사용해 얻을 수 있습니다.

Origin Set의 크기는 이 명세에서 제한되지 않으므로 공격자가 클라이언트 자원을 고갈시키는 데 이를 사용할 수 있습니다. 이 위험을 완화하기 위해 클라이언트는 상태 커미트먼트(state commitment)를 모니터링하고 너무 커지면 연결을 닫을 수 있습니다.

5. 참조

5.1. 규범 참조

[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818]: Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC5280]: Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC6066]: Eastlake 3rd, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6454]: Barth, A., “The Web Origin Concept”, RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC7540]: Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[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>.

5.2. 정보 참조

[RFC6960]: Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP”, RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6962]: Laurie, B., Langley, A., and E. Kasper, “Certificate Transparency”, RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC7230]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7838]: Nottingham, M., McManus, P., and J. Reschke, “HTTP Alternative Services”, RFC 7838, DOI 10.17487/RFC7838, April 2016, <http://www.rfc-editor.org/info/rfc7838>.
[RFC8288]: Nottingham, M., “Web Linking”, RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.

Appendix A. 비규범 처리 알고리즘

다음 알고리즘은 클라이언트가 수신한 ORIGIN 프레임을 처리하는 방법의 예시를 보여줍니다:

If the client is configured to use a proxy for the connection, ignore the frame and stop processing.
If the connection is not identified with the "h2" protocol identifier or another protocol that has explicitly opted into this specification, ignore the frame and stop processing.
If the frame occurs upon any stream except stream 0, ignore the frame and stop processing.
If any of the flags 0x1, 0x2, 0x4, or 0x8 are set, ignore the frame and stop processing.
If no previous ORIGIN frame on the connection has reached this step, initialize the Origin Set as per Section 2.3.
For each Origin-Entry in the frame payload:
1. Parse ASCII-Origin as an ASCII serialization of an origin ([RFC6454], Section 6.2), and let the result be parsed_origin. If parsing fails, skip to the next Origin-Entry.
2. Add parsed_origin to the Origin Set.

Appendix B. 서버 운영 고려사항

ORIGIN 프레임은 서버가 특정 연결을 어떤 오리진에 대해 사용해야 하는지를 표시할 수 있게 합니다. 이 메커니즘을 통해 광고되는 오리진 집합은 서버의 제어 하에 있으며; 서버는 이를 사용하거나 자신이 응답할 수 있는 모든 오리진을 광고할 의무는 없습니다.

예를 들어, 빈 ORIGIN 프레임을 보내 연결이 SNI 기반 오리진에만 사용되어야 함을 클라이언트에 알릴 수 있습니다. 또는 페이로드를 포함하여 더 많은 오리진을 표시할 수 있습니다.

일반적으로 이 정보는 새로운 연결을 시작할 수 있는 응답의 어떤 부분을 보내기 전에 전송하는 것이 가장 유용합니다. 예를 들어 "Link" 응답 헤더 필드([RFC8288])나 응답 본문의 링크들처럼요.

따라서 ORIGIN 프레임은 가능하면 연결에서 가능한 한 빨리, 이상적으로는 어떤 HEADERS나 PUSH_PROMISE 프레임보다 먼저 전송되어야 합니다.

하지만 많은 수의 오리진을 연결과 연관시키는 것이 바람직하다면, 그 크기 때문에 최종 사용자에게 인지되는 지연을 초래할 수 있습니다. 따라서 초기에는 "핵심" 오리진 집합을 선택하여 전송하고, 이후(예: 연결이 유휴일 때) 추가 ORIGIN 프레임으로 오리진 집합을 확장하는 것이 필요할 수 있습니다.

그럼에도 불구하고 발신자는 가능한 한 많은 오리진을 단일 ORIGIN 프레임에 포함시키는 것이 권장됩니다; 클라이언트는 즉석에서 연결 생성에 대한 결정을 내려야 하고, Origin Set이 여러 프레임에 분산되면 동작이 최적이 아닐 수 있습니다.

발신자는 [RFC6454]의 섹션 4, 단계 5에 따라 ORIGIN 헤더의 값들이 직렬화되기 전에 대소문자 정규화(case-normalization)되어야 한다는 점을 유념하십시오.

마지막으로, 대체 서비스를 호스트하는 서버는 ORIGIN을 보낼 때 오리진을 명시적으로 광고해야 합니다([RFC7838] 참조). 이는 Origin Set의 기본 내용(섹션 2.3 참조)이 연결에서 이전에 사용되었더라도 어떤 대체 서비스 오리진도 포함하지 않기 때문입니다.

저자 주소

Mark Nottingham
EMail: mnot@mnot.net
URI: https://www.mnot.net/

Erik Nygren
Akamai
EMail: nygren@akamai.com