TLS S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Experimental 24 July 2022
Expires: 25 January 2023
A well-known URI for publishing ECHConfigList values. draft-ietf-tls-wkech-00
Echconfiglist値を公開するためのよく知られているURI。ドラフト-iTf-tls-wkech-00
Abstract
概要
We propose use of a well-known URI at which web servers can publish ECHConfigList values as a way to help get those published in the DNS.
WebサーバーがDNSで公開されるものを支援する方法として、WebサーバーがEchconfiglist Valuesを公開できる有名URIの使用を提案します。
Status of This Memo
本文書の位置付け
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に適合して提出されています。
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
インターネットドラフトは、インターネットエンジニアリングタスクフォース（IETF）の作業文書です。他のグループは、作業文書をインターネットドラフトとして配布する場合もあることに注意してください。現在のインターネットドラフトのリストは、https：//datatracker.ietf.org/drafts/current/にあります。
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."
インターネットドラフトは、最大6か月間有効なドラフトドキュメントであり、いつでも他のドキュメントで更新、交換、または廃止される場合があります。インターネットドラフトを参照資料として使用したり、「進行中の作業」以外に引用することは不適切です。
This Internet-Draft will expire on 25 January 2023.
このインターネットドラフトは、2023年1月25日に期限切れになります。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Example use of the well-known URI for ECH . . . . . . . . . . 3
4. The ech well-known URI . . . . . . . . . . . . . . . . . . . 3
5. The JSON structure for ECHConfigList values . . . . . . . . . 4
6. Zone factory behaviour . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
Encrypted ClientHello (ECH) [I-D.ietf-tls-esni] for TLS1.3 [RFC8446] defines a confidentiality mechanism for server names and other ClientHello content in TLS. For many applications, that requires publication of ECHConflgList data structures in the DNS. An ECHConfigList structure contains a list of ECHConfig values. Each ECHConfig value contains the public component of a key pair that will typically be periodically (re-)generated by a web server. Many web infrastructures will have an API that can be used to dynamically update the DNS RR values containing ECHConfigList values. Some deployments however, will not, so web deployments could benefit from a mechanism to use in such cases.
TLS1.3 [RFC8446]の暗号化されたClientHello（ECH）[I-D.IETF-TLS-ESNI]は、TLSのサーバー名およびその他のClientHelloコンテンツの機密メカニズムを定義します。多くのアプリケーションでは、DNSでのeChConflglistデータ構造の公開が必要です。eChConfiglist構造には、eChConfig値のリストが含まれています。各eChConfig値には、通常、Webサーバーによって定期的に（再）生成されるキーペアのパブリックコンポーネントが含まれています。多くのWebインフラストラクチャには、eChConfiglist値を含むDNS RR値を動的に更新するために使用できるAPIがあります。ただし、一部の展開はそうではないため、Webの展開は、そのような場合に使用するメカニズムの恩恵を受ける可能性があります。
We define such a mechanism here. Note that this is not intended for universal deployment, but rather for cases where the web server doesn't have write access to the relevant zone file (or equivalent). That zone file will eventually include an HTTPS or SVCB RR [I-D.ietf-dnsop-svcb-https] containing an ECHConfigList.
ここでは、このようなメカニズムを定義します。これは、ユニバーサルの展開を目的としているのではなく、Webサーバーが関連するゾーンファイル（または同等）に書き込みアクセスを持たない場合に対象としています。そのゾーンファイルには、最終的にHTTPSまたはSVCB RR [I-D.IETF-DNSOP-SVCB-HTTPS]が含まれます。
We use the term "zone factory" for the entity that does have write access to the zone file. We assume the zone factory (ZF) can also make HTTPS requests to the web server with the ECH keys.
ゾーンファイルへの書き込みアクセスがあるエンティティには、「ゾーンファクトリ」という用語を使用します。Zone Factory（ZF）は、ECHキーを使用してWebサーバーにHTTPSリクエストを作成できると仮定します。
We propose use of a well-known URI [RFC8615] on the web server that allows ZF to poll for changes to ECHConfigList values. For example, if a web server generates new ECHConfigList values hourly and publishes those at the well-known URI, ZF can poll that URI. When ZF sees new values, it can check if those work, and if they do, then update the zone file and re-publish the zone.
Webサーバーでよく知られているURI [RFC8615]を使用することを提案し、ZFがeChConfiglist値の変更を投票できるようにします。たとえば、Webサーバーが1時間ごとに新しいeChConfiglist値を生成し、有名なURIでそれらを公開すると、ZFはそのURIを投票できます。ZFが新しい値を確認したら、それらの動作とそれらが行われるかどうかを確認できます。ゾーンファイルを更新してゾーンを再発行します。
[[The source for this is in https://github.com/sftcd/wkesni/ PRs are
welcome there too.]]
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
An example deployment could be as follows:
展開の例は次のとおりです。
* Web server generates new ECHConfigList values hourly at N past the hour via a cronjob * ECHConfigList values are "current" for an hour, published with a TTL of 1800, and remain usable for 3 hours from the time of generation * Web server has a set of "backend" sites - the DNS name for each such site is here represented as $BACKEND, which will end up as an SNI value to be encrypted inside an ECH extension * Web server has a "front-end" site ($FRONT), where $FRONT will typically be the DNS name used in the ECHConfigList public_name field for ECHConfig version 0xff0d * A cronjob creates creates a JSON file for each backend site at https://$FRONT/.well-known/ech/$BACKEND.json * Each JSON file contains an array with the ECHConfigList values values for that particular $BACKEND as shown in Figure 1 - the values in Figure 1 with ellipses are the values we want to eventually see in the DNS * On the zone factory, a cronjob runs at N+3 past the hour, it knows all the names involved and checks to see if the content at those well-known URIs has changed or not * If the content has changed the cronjob attempts to use the ECHConfigList values, and for each $BACKEND where that works, it updates the zone file and re-publishes the zone containing only the new ECHConfigList values
* Webサーバーは、cronjobを介して1時間のnで1時間ごとに新しいechconfiglist値を生成します * echconfiglist値は1時間「最新」であり、1800のTTLで公開され、世代の時点から3時間使用可能です * Webサーバーにはセットがあります「バックエンド」サイトの - そのような各サイトのDNS名は$ backendとして表されます。これは、ECH拡張機能 * Webサーバー内で暗号化されるSNI値として最終的に表現されます。 、$ frontは通常、echconfiglist public_nameフィールドで使用されるdns名ですechconfigバージョン0xff0d * cronjobは、https/.well-nown/ech/packendendで各バックエンドサイトのJSONファイルを作成します。 JSON *各JSONファイルには、図1に示すように、その特定の$バックエンドのeChConfiglist値の値を持つ配列が含まれています。 1時間過ぎてn 3で実行され、関連するすべての名前を知っており、sにチェックしますEE有名なURIのコンテンツが変更されたかどうか *コンテンツが変更された場合 * CronjobがEchconfiglist値を使用しようとします。新しいeChConfiglist値のみ
When a web server ($FRONT) wants to publish ECHConfigList information
for a backend site ($BACKEND) then it provides the JSON content
defined in Section 5 at: https://$FRONT/.well-known/ech/$BACKEND.json
The well-known URI defined here MUST be an https URL and therefore the zone factory verifies the correct $FRONT is being accessed. If there is any failure in accessing the well-known URI, then the zone factory MUST NOT modify the zone.
ここで定義されているよく知られているURIはHTTPS URLである必要があります。したがって、ゾーンファクトリは正しい$フロントがアクセスされていることを検証します。よく知られているURIへのアクセスに障害がある場合、ゾーンファクトリーはゾーンを変更してはなりません。
[[Since the specifics of the JSON structure in Figure 1 are very likely to change, this is mostly TBD. What is here for now, is what the author has currently implemented simply because it worked ok and was easy to do:-) One issue raised as a result of the dispatch presentation is whether or not anything beyond the ECHConfigList might make sense to represent in the JSON response. One example could be the inner ClientHello ALPN extension, if that might somehow be useful to the TLS cilent (which really should know in that case). The scope in that respect and the correct level of generality to cover here is something to consider as this evolves.]]
[[図1のJSON構造の詳細は変化する可能性が非常に高いため、これはほとんどTBDです。今のところここにあるのは、著者が現在実装していることです。それがうまくいっていて簡単だったからです:-)派遣プレゼンテーションの結果として提起された1つの問題は、eChconfiglist以外の何かが表現するのが理にかなっているかどうかですJSON応答。1つの例は、TLS Cilent（その場合は実際に知っておくべき）に何らかの形で役立つ可能性がある場合、内側のclienthello alpn拡張機能です。その点の範囲とここでカバーする正しいレベルの一般性は、これが進化するにつれて考慮すべきことです。]]
[
{
"desired-ttl": 1800,
"ports": [ 443, 8413 ],
"echconfiglist": "AD7+DQA65wAgAC..AA=="
},
{
"desired-ttl": 1800,
"ports": [ 443, 8413 ],
"echconfiglist": "AD7+DQA65wAgAC..AA=="
}
]
Figure 1: Sample JSON
図1：サンプルJSON
The JSON file at the well-known URI MUST contain an array with one or more elements. Each element of the array MUST have these fields:
よく知られているURIのJSONファイルには、1つ以上の要素がある配列が含まれている必要があります。配列の各要素には、これらのフィールドが必要です。
* desired-ttl: contains a number indicating the TTL that the web server would like to see used for this RR. The zone factory MUST NOT use a longer TTL. * ports: this has a list of the TCP ports on which the web server with the relevant key pair will listen (needed to produce the correct zone file). * ECHConfigList: contains the value to be used as a base64 encoded string.
* 目的TTL：WebサーバーがこのRRに使用することを望んでいるTTLを示す数字が含まれています。ゾーンファクトリは、より長いTTLを使用してはなりません。*ポート：これには、関連するキーペアを持つWebサーバーが聞く（正しいゾーンファイルを生成するために必要）TCPポートのリストがあります。* ECHCONFIGLIST：base64エンコード文字列として使用する値が含まれています。
The JSON file contains an array for a couple of reasons:
JSONファイルには、いくつかの理由で配列が含まれています。
* As TLS authentication doesn't really distinguish ports, servers on the same host could in any case cheat on one another, so we may as well just read one JSON file per name. * Different ports could map to different sets of ECHConfig values
* TLS認証は実際にはポートを区別していないため、同じホストのサーバーがいずれにせよ互いにチートすることができるため、名前ごとに1つのJSONファイルを読み取ることもできます。*異なるポートは、異なるセットのechconfig値にマッピングできます
* As ECHConfigList is (regrettably:-) an extensible structure, it may be necessary to publish different ECHConfigList values to get best interoperability.
* eChConfiglistは（残念ながら:-)拡張可能な構造であるため、最適な相互運用性を得るために、異なるeChConfiglist値を公開する必要がある場合があります。
The zone factory SHOULD check that the presented ECHConfigList values work with the $BACKEND server before publication. A "special" TLS client may be needed for this check, that does not require the ECHConfigList value to have already been published in the DNS. [[I guess that calls for the zone factory to know of a "safe" URL on $BACKEND to try, or maybe it could use HTTP HEAD? Figuring that out is TBD. The ZF could also try a GREASEd ECH and see if the retry-configs it gets back is one of the ECHConfig values in the ECHConfigList.]]
Zone Factoryは、提示されたEchconfiglist値が公開前に$ Backendサーバーで動作することを確認する必要があります。このチェックには「特別な」TLSクライアントが必要になる場合があります。これは、eChConfiglist値がDNSで既に公開されている必要はありません。[[ゾーン工場に$バックエンドの「安全な」URLを試してみることを求めているのか、それともhttpヘッドを使用できると思いますか？それを理解するのはTBDです。ZFは、グリースを塗ったechを試して、それが戻すRetryConfigがechconfiglistのechconfig値の1つであるかどうかを確認することもできます。]]]
A careful zone factory could explode the ECHConfigList value presented into "singleton" values with one public key in each and test each for each port claimed.
慎重なゾーンファクトリーは、「シングルトン」値に提示されたエクセルフィグリスト値を、それぞれに1つの公開キーで爆発させ、各ポートが請求される各ポートについてテストすることができます。
The zone factory SHOULD publish all the ECHConfigList values that are presented in the JSON file, and that pass the check above.
ゾーンファクトリは、JSONファイルに表示されているすべてのeChConfiglist値を公開する必要があり、上記のチェックに合格する必要があります。
The zone factory SHOULD only publish ECHConfigList values that are in the latest version of the JSON file. This leaves the control of "expiry" with the web server, so long as the ECHConfigList values presented actually work. [[An alternative could be to have the new values just be appended to the zone, but that'd require some form of "notAfter" value in the JSON file which seems unnecessary and more complex.]]
Zone Factoryは、JSONファイルの最新バージョンにあるEchconfiglist値のみを公開する必要があります。これにより、ECHCONFIGLIST値が実際に機能する限り、Webサーバーで「有効期限」の制御が残ります。[[別の方法は、新しい値をゾーンに追加することですが、JSONファイルには不必要で複雑に見える「Notafter」値の形式が必要でした。]]]
The SCVB and HTTPS RR specification [I-D.ietf-dnsop-svcb-https] defines how and where the ECHConfigList values for $BACKEND needs to be published in the DNS. The zone factory is assumed to be in control of how ECHConfigList values are included in such RRs.
SCVBおよびHTTPS RR仕様[I-D.IETF-DNSOP-SVCB-HTTPS]は、$バックエンドのEchconfiglist値をDNSで公開する方法と場所を定義します。ゾーンファクトリは、エクセルフィグリスト値がそのようなRRにどのように含まれているかを制御していると想定されています。
A possibly interesting (unintended) consequence of this design is that once a TLS client has first gotten an ECHConfigList from the DNS for $BACKEND with the ECHConfigList structure containing the public_name field, the TLS client would know both $FRONT and $BACKEND and so could later probe for this .well-known as an alternative to doing so via DoT/DoH. Probably not something a web browser might do, but could be fun for other applications maybe.
この設計のおそらく興味深い（意図しない）結果は、TLSクライアントが最初に$バックエンドのeChConfiglistを$バックエンドのECHCONFIGLIST構造を使用して、TLSクライアントが$フロントと$バックエンドの両方を知っていることです。このための後のプローブは、DOT/DOHを介してそうすることに代わるものとして知られています。おそらく、Webブラウザーがするかもしれないことではありませんが、他のアプリケーションにとっては楽しいかもしれません。
[[The extent to which retry-configs could be used for a similar purpose might be worth considering. But the JSON stuff here may still be needed if implementations (such as mine:-) tend to only return one ECHConfig in retry-configs.]]
[[RetryConfigsを同様の目的に使用できる程度は、検討する価値があるかもしれません。しかし、実装（私のものなどの実装:-)は、retryConfigsで1つのeChconfigのみを返す傾向がある場合でも、ここのJSONのものが必要になる場合があります。]]]]
This document defines another way to publish ECHConfigList values. If the wrong keys were read from here and published in the DNS, then clients using ECH would do the wrong thing, likely resulting in denial of service, or a privacy leak, or worse, when TLS clients attempt to use ECH with a backend web site. So: Don't do that:-)
このドキュメントでは、Echconfiglist値を公開する別の方法を定義します。間違ったキーがここから読み取られ、DNSで公開された場合、ECHを使用してクライアントが間違ったことを行い、おそらくサービスの拒否、またはプライバシーリークを引き起こす可能性があります。サイト。だから：それをしないでください:-)
Thanks to Niall O'Reilly for a quick review of -00.
-00の簡単なレビューをしてくれたNiall O'Reillyに感謝します。
[[TBD: IANA registration of a .well-known. Also TBD - how to handle I18N for $FRONT and $BACKEND within such a URL.]]
[[TBD：IANAの登録。また、TBD-そのようなURL内の$フロントと$バックエンドでi18nを処理する方法。]]]
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<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>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", DOI 10.17487/RFC8615, RFC 8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[RFC8615]ノッティンガム、M。、「よく知られているユニフォームリソース識別子（URIS）」、DOI 10.17487/RFC8615、RFC 8615、2019年5月、<https://www.rfc-editor.org/info/rfc8615>
[I-D.ietf-tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-14, 13 February 2022, <https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.txt>.
[i-d.ietf-tls-esni] Rescorla、E.、Oku、K.、Sullivan、N。、およびC. A. Wood、「TLS暗号化クライアントHello」、Work in Progress、Internet-Draft、Draft-Tls-Esni-14、2022年2月13日、<https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.txt>。
[I-D.ietf-dnsop-svcb-https] Schwartz, B., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-dnsop-svcb-https-10, 24 May 2022, <https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-10.txt>.
[i-d.ietf-dnsop-svcb-https] Schwartz、B.、Bishop、M。、およびE. Nygren、「DNS（DNS SVCBおよびHTTPS RRS）を介したサービス拘束力とパラメーター仕様」、進行中の作業、インターネット - ドラフト、ドラフト-ITETF-DNSOP-SVCB-HTTPS-10、2022年5月24日、<https://www.ietf.org/id/draft-ietf-dnsop-svcb-https-10.txt>。
[[RFC editor: please remove this before publication.]]
[[RFCエディター：公開前にこれを削除してください。]]
The -00 WG draft replaces draft-farrell-tls-wkesni-03.
-00 WGドラフトは、ドラフトファレル-TLS-WKESNI-03に取って代わります。
Author's Address
著者の住所
Stephen Farrell Trinity College Dublin Dublin 2 Ireland Phone: +353-1-896-2354 Email: stephen.farrell@cs.tcd.ie
スティーブンファレルトリニティカレッジダブリンダブリン2アイルランド電話：353-1-896-2354メール：stephen.farrell@cs.tcd.ie