RFC 8467 - Padding Policies for Extension Mechanisms for DNS (EDNS(0)) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8467
タイトル : RFC 8467 - DNSの拡張メカニズムのパディングポリシー（EDNS（0））
翻訳編集 : 自動生成

[要約] RFC 8467は、DNSの拡張メカニズムであるEDNS(0)のパディングポリシーに関するものであり、DNSトラフィックのセキュリティを向上させるために設計されています。このRFCの目的は、パディングの使用方法とポリシーを定義し、攻撃者によるトラフィック解析を困難にすることです。

Internet Engineering Task Force (IETF)                      A. Mayrhofer
Request for Comments: 8467                                   nic.at GmbH
Category: Experimental                                      October 2018
ISSN: 2070-1721

Padding Policies for Extension Mechanisms for DNS (EDNS(0))

DNSの拡張メカニズムのパディングポリシー（EDNS（0））

Abstract

概要

RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.

RFC 7830は、DNSの拡張メカニズム（EDNS（0））の「パディング」オプションを指定していますが、特定のアプリケーションの実際のパディング長は指定していません。このメモは、可能なオプション（「埋め込みポリシー」）をリストし、各オプションの意味を説明し、推奨される（実験的な）オプションを提供します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8467.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8467で入手できます。

著作権表示

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. General Guidance ................................................3
   4. Padding Strategies ..............................................3
      4.1. Recommended Strategy: Block-Length Padding .................3
      4.2. Other Strategies ...........................................5
           4.2.1. Maximal-Length Padding ..............................5
           4.2.2. Random-Length Padding ...............................5
           4.2.3. Random-Block-Length Padding .........................6
   5. IANA Considerations .............................................6
   6. Security Considerations .........................................6
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................7
   Appendix A.  Padding Policies That Are Not Sensible ................8
     A.1.  No Padding .................................................8
     A.2.  Fixed-Length Padding .......................................8
   Acknowledgements ...................................................9
   Author's Address ...................................................9

1. Introduction

1. はじめに

[RFC7830] specifies the Extension Mechanisms for DNS (EDNS(0)) "Padding" option, which allows DNS clients and servers to artificially increase the size of a DNS message by a variable number of bytes, hampering size-based correlation of encrypted DNS messages.

[RFC7830]は、DNSの拡張メカニズム（EDNS（0））の「パディング」オプションを指定します。これにより、DNSクライアントとサーバーは、可変バイト数でDNSメッセージのサイズを作為的に増やし、暗号化されたDNSのサイズベースの相関を妨げます。メッセージ。

However, RFC 7830 deliberately does not specify the actual length of padding to be used. This memo discusses options regarding the actual size of padding, lists advantages and disadvantages of each of these "padding strategies", and provides a recommended (experimental) strategy.

ただし、RFC 7830では、使用するパディングの実際の長さを意図的に指定していません。このメモでは、パディングの実際のサイズに関するオプションについて説明し、これらの各「パディング戦略」の利点と欠点を示し、推奨される（実験的な）戦略を提供します。

Padding DNS messages is useful only when transport is encrypted using protocols such as DNS over Transport Layer Security [RFC7858], DNS over Datagram Transport Layer Security [RFC8094], or other encrypted DNS transports specified in the future.

DNSメッセージのパディングは、トランスポートがDNS over Transport Layer Security [RFC7858]、DNS over Datagram Transport Layer Security [RFC8094]、または将来指定される他の暗号化されたDNSトランスポートなどのプロトコルを使用して暗号化されている場合にのみ役立ちます。

2. Terminology

2. 用語

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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. General Guidance

3. 一般的なガイダンス

EDNS(0) options space: The maximum message length, as dictated by the protocol, limits the space for EDNS(0) options. Since padding will reduce the message space available to other EDNS(0) options, the "Padding" option MUST be the last EDNS(0) option applied before a DNS message is sent.

EDNS（0）オプションのスペース：プロトコルで指定されている最大メッセージ長により、EDNS（0）オプションのスペースが制限されます。パディングは他のEDNS（0）オプションで使用できるメッセージスペースを減らすため、「パディング」オプションは、DNSメッセージが送信される前に適用される最後のEDNS（0）オプションである必要があります。

Resource Conservation: Especially in situations where networking and processing resources are scarce (e.g., battery-powered long-life devices, low bandwidth, or high-cost links), the trade-off between increased size of padded DNS messages and the corresponding gain in confidentiality must be carefully considered.

リソースの節約：特にネットワーキングと処理のリソースが不足している状況（たとえば、バッテリー駆動の長寿命デバイス、低帯域幅、または高コストのリンク）では、パッド入りDNSメッセージのサイズの増加とそれに対応するゲインのトレードオフ機密性は慎重に検討する必要があります。

Transport Protocol Independence: The message size used as input to the various padding strategies MUST be calculated excluding the potential extra 2-octet length field used in TCP transport. Otherwise, the padded (observable) size of the DNS packets could significantly change between different transport protocols and reveal an indication of the original (unpadded) length. For example, given a Block-Length Padding strategy with a block length of 32 octets and a DNS message with a size of 59 octets, the message would be padded to 64 octets when transported over UDP. If that same message were transported over TCP and the padding strategy considered the extra 2 octets of the length field (61 octets in total), the padded message would be 96 octets long (as the minimum length of the "Padding" option is 4 octets).

トランスポートプロトコルの独立性：さまざまなパディング戦略への入力として使用されるメッセージサイズは、TCPトランスポートで使用される潜在的な追加の2オクテット長フィールドを除いて計算する必要があります。そうしないと、DNSパケットのパディングされた（監視可能な）サイズが異なるトランスポートプロトコル間で大幅に変化し、元の（パディングされていない）長さの表示が明らかになる可能性があります。たとえば、ブロック長が32オクテットのブロック長パディング戦略とサイズが59オクテットのDNSメッセージがある場合、メッセージはUDPで転送されるときに64オクテットにパディングされます。同じメッセージがTCPを介して転送され、パディング戦略が長さフィールドの追加の2オクテット（合計61オクテット）を考慮した場合、パディングメッセージは96オクテット長になります（「パディング」オプションの最小長は4オクテットであるため））。

4. Padding Strategies

4. パディング戦略

This section contains a recommended strategy, as well as a non-exhaustive list of other sensible strategies, for choosing padding length. Note that, for completeness, Appendix A contains two more strategies that are not sensible.

このセクションには、パディング長を選択するための推奨戦略と、他の賢明な戦略の完全なリストが含まれています。完全を期すために、付録Aには実用的でない2つの戦略が含まれていることに注意してください。

4.1. Recommended Strategy: Block-Length Padding

4.1. 推奨される戦略：ブロック長のパディング

Based on empirical research performed by Daniel K. Gillmor [NDSS-PADDING], padding SHOULD be performed following the Block-Length Padding strategy as follows:

ダニエルK.ギルモア[NDSS-PADDING]による実証的研究に基づいて、次のようにブロック長パディング戦略に従ってパディングを実行する必要があります。

(1) Clients SHOULD pad queries to the closest multiple of 128 octets.

（1）クライアントは、クエリを最も近い128オクテットの倍数にパディングする必要があります（SHOULD）。

(2) If a server receives a query that includes the EDNS(0) "Padding" option, it MUST pad the corresponding response (see Section 4 of RFC 7830) and SHOULD pad the corresponding response to a multiple of 468 octets (see below).

（2）サーバーがEDNS（0）の「パディング」オプションを含むクエリを受信した場合、対応する応答を埋める必要があり（RFC 7830のセクション4を参照）、対応する応答を468オクテットの倍数にパディングする必要があります（下記を参照）。）。

Note that the recommendation above only applies if the DNS transport is encrypted (see Section 6 of RFC 7830).

上記の推奨事項は、DNSトランスポートが暗号化されている場合にのみ適用されます（RFC 7830のセクション6を参照）。

In Block-Length Padding, a sender pads each message so that its padded length is a multiple of a chosen block length. This creates a greatly reduced variety of message lengths. An implementor needs to consider that even the zero-length "Padding" option increases the length of the packet by 4 octets.

Block-Length Paddingでは、送信者は各メッセージにパディングして、パディングされた長さが選択されたブロック長の倍数になるようにします。これにより、さまざまなメッセージ長が大幅に削減されます。実装者は、長さがゼロの「パディング」オプションでさえ、パケットの長さが4オクテット増えることを考慮する必要があります。

Options: Block length. For queries, values between 16 and 128 octets were discussed before empiric research was performed. Responses will require larger block sizes (see [NDSS-PADDING] and above for a discussion).

オプション：ブロック長。クエリについては、16〜128オクテットの値について、実証的な調査が行われる前に議論されました。応答には、より大きなブロックサイズが必要になります（説明については、[NDSS-PADDING]以上を参照してください）。

Very large block lengths will have confidentiality properties similar to the Maximal-Length Padding strategy (Section 4.2.1), since almost all messages will fit into a single block. Such "very large block length" values are:

非常に長いブロック長は、ほとんどすべてのメッセージが1つのブロックに収まるため、最大長パディング戦略（セクション4.2.1）と同様の機密性プロパティを備えています。そのような「非常に大きなブロック長」の値は次のとおりです。

o 288 bytes for the query (the maximum size of a one-question query over TCP, without any EDNS(0) options) and

o クエリ用に288バイト（TCPを介した1質問クエリの最大サイズ、EDNS（0）オプションなし）、および

o the EDNS(0) buffer size of the server for the responses.

o 応答用のサーバーのEDNS（0）バッファーサイズ。

Advantages: This policy is reasonably easy to implement, reduces the variety of message ("fingerprint") sizes significantly, and does not require a source of (pseudo) random numbers, since the padding length required can be derived from the actual (unpadded) message.

利点：このポリシーは適度に簡単に実装でき、メッセージ（「フィンガープリント」）のサイズを大幅に削減し、（疑似）乱数のソースを必要としません。必要なパディングの長さは実際の（パディングされていない）から導出できるためです。メッセージ。

Disadvantage: Given an unpadded message and the block size of the padding (which is assumed to be public knowledge once a server is reachable), the size range of a padded message can be predicted. Therefore, the minimum length of the unpadded message can be inferred.

短所：パディングされていないメッセージとパディングのブロックサイズ（サーバーが到達可能になった時点でパブリックナレッジであると見なされる）が与えられると、パディングされたメッセージのサイズ範囲を予測できます。したがって、パディングされていないメッセージの最小長を推測できます。

The empirical research cited above performed a simulation of padding, based on real-world DNS traffic captured on busy recursive resolvers of a research network. The evaluation of the performance of individual padding policies was based on a "cost to attacker" and "cost to defender" function, where the "cost to attacker" was defined as the percentage of query/response pairs falling into the same size bucket and "cost to defender" was defined as the size factor between padded and unpadded messages. Padding with a block size of 128 bytes on the query side and 468 bytes on the response side was considered the optimum trade-off between defender and attacker cost. The response block size of 468 was chosen so that 3 blocks of 468 octets would still comfortably fit into typical Maximum Transmission Unit (MTU) size values.

上記の実証研究では、研究ネットワークの多忙な再帰リゾルバでキャプチャされた実際のDNSトラフィックに基づいて、パディングのシミュレーションを実行しました。個々のパディングポリシーのパフォーマンスの評価は、「攻撃者へのコスト」および「防御者へのコスト」関数に基づいていました。「攻撃者へのコスト」は、同じサイズのバケットに分類されるクエリ/応答ペアの割合として定義され、「防御するためのコスト」は、埋め込みメッセージと非埋め込みメッセージの間のサイズ係数として定義されました。クエリ側で128バイト、応答側で468バイトのブロックサイズのパディングは、防御側と攻撃側のコスト間の最適なトレードオフと見なされていました。 468オクテットの3つのブロックが通常の最大伝送ユニット（MTU）サイズ値に快適に適合するように、468の応答ブロックサイズが選択されました。

The block size will interact with the MTU size. Especially for length values that are a large fraction of the MTU, unless the block length is chosen so that a multiple just fits into the MTU, Block-Length Padding may cause unnecessary fragmentation for UDP-based delivery. Of course, choosing a block length larger than the MTU always forces fragmentation.

ブロックサイズはMTUサイズと相互作用します。特にMTUの大部分を占める長さの値の場合、複数がMTUにちょうど収まるようにブロック長を選択しない限り、ブロック長パディングはUDPベースの配信で不要な断片化を引き起こす可能性があります。もちろん、MTUよりも大きいブロック長を選択すると、常にフラグメンテーションが強制されます。

Note: Once DNSSEC-validating clients become more prevalent, observed size patterns are expected to change significantly. In that case, the recommended strategy might need to be revisited.

注：DNSSEC検証クライアントが普及すると、観測されたサイズパターンは大幅に変化すると予想されます。その場合、推奨される戦略を再検討する必要があるかもしれません。

4.2. Other Strategies

4.2. その他の戦略

4.2.1. Maximal-Length Padding

4.2.1. 最大長のパディング

In Maximal-Length Padding, the sender pads every message to the maximum size allowed by protocol negotiations.

最大長パディングでは、送信者はすべてのメッセージにプロトコルネゴシエーションで許可されている最大サイズまでパディングします。

Advantages: Maximal-Length Padding, when combined with encrypted transport, provides the highest possible level of message-size confidentiality.

利点：最大長のパディングを暗号化されたトランスポートと組み合わせると、可能な限り最高レベルのメッセージサイズの機密性が提供されます。

Disadvantages: Maximal-Length Padding is wasteful and requires resources on the client, all intervening networks and equipment, and the server. Depending on the negotiated size, this strategy will commonly exceed the MTU and result in a consistent number of fragments, reducing delivery probability when datagram-based transport (such as UDP) is used.

短所：最大長のパディングは無駄が多く、クライアント、介在するすべてのネットワークと機器、サーバー上のリソースを必要とします。ネゴシエートされたサイズに応じて、この戦略は通常MTUを超え、フラグメントの数が一定になるため、データグラムベースのトランスポート（UDPなど）が使用される場合の配信確率が低下します。

Due to resource consumption, Maximal-Length Padding is NOT RECOMMENDED.

リソース消費のため、最大長のパディングは推奨されません。

4.2.2. Random-Length Padding

4.2.2. ランダム長のパディング

When using Random-Length Padding, a sender pads each message with a random amount of padding. Due to the size of the "Padding" option itself, each message size is increased by at least 4 octets. The upper limit for padding is the maximum message size. However, a client or server may choose to impose a lower maximum padding length.

Random-Length Paddingを使用する場合、送信者は各メッセージにランダムな量のパディングを埋め込みます。「パディング」オプション自体のサイズにより、各メッセージサイズは少なくとも4オクテット増加します。パディングの上限は最大メッセージサイズです。ただし、クライアントまたはサーバーは、より短い最大パディング長を課すことを選択できます。

Options: Maximum and minimum padding length.

オプション：最大および最小のパディング長。

Advantages: Theoretically, this policy should create a natural distribution of message sizes.

利点：理論的には、このポリシーはメッセージサイズの自然な分布を作成する必要があります。

Disadvantage: Random-Length Padding allows an attacker who can observe a large number of requests to infer the length of the original value by observing the distribution of total lengths.

欠点：ランダムな長さのパディングにより、攻撃者は多数のリクエストを観察できるため、全長の分布を観察して元の値の長さを推測できます。

According to the limited empirical data available, Random-Length Padding exposes slightly more entropy to an attacker than Block-Length Padding. Because of that, and the risk outlined above, Random-Length Padding is NOT RECOMMENDED.

利用可能な限られた経験的データによると、ランダム長パディングは、ブロック長パディングよりもわずかに多くのエントロピーを攻撃者に公開します。そのため、上記のリスクがあるため、ランダム長のパディングは推奨されません。

4.2.3. Random-Block-Length Padding

4.2.3. ランダムブロック長のパディング

This policy combines Block-Length Padding with a random component. Specifically, a sender randomly chooses between a few block length values and then applies Block-Length Padding based on the chosen block length. The random selection of block length might even be reasonably based on a "weak" source of randomness, such as the transaction ID of the message.

このポリシーは、ブロック長パディングとランダムコンポーネントを組み合わせます。具体的には、送信者はいくつかのブロック長の値からランダムに選択し、選択したブロック長に基づいてブロック長パディングを適用します。ブロック長のランダムな選択は、メッセージのトランザクションIDなど、ランダム性の「弱い」ソースに合理的に基づいている場合もあります。

Options: Number of and the values for the set of block lengths; source of randomness

オプション：ブロック長のセットの数と値。ランダムのソース

Advantages: Compared to Block-Length Padding, this creates more variety in the resulting message sizes for a certain individual original message length.

利点：ブロック長のパディングと比較して、これは特定の個々の元のメッセージ長の結果のメッセージサイズにより多様性をもたらします。

Disadvantage: Requires more implementation effort compared to simple Block-Length Padding.

短所：単純なブロック長のパディングと比較して、より多くの実装作業が必要です。

Random-Block-Length Padding requires further empirical study, as do other combinations of padding strategies.

ランダムブロック長のパディングは、パディング戦略の他の組み合わせと同様に、さらに経験的な調査が必要です。

5. IANA Considerations

5. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

6. Security Considerations

6. セキュリティに関する考慮事項

The choice of the right padding policy (and the right parameters for the chosen policy) has a significant impact on the resilience of encrypted DNS against size-based correlation attacks. Therefore, any implementor of the "Padding" option must carefully consider which policies to implement, the default policy chosen, which parameters to make configurable, and the default parameter values.

適切なパディングポリシー（および選択したポリシーの適切なパラメーター）の選択は、サイズベースの相関攻撃に対する暗号化されたDNSの回復力に大きな影響を与えます。したがって、「パディング」オプションの実装者は、実装するポリシー、選択したデフォルトのポリシー、構成可能にするパラメーター、およびデフォルトのパラメーター値を慎重に検討する必要があります。

No matter how carefully a client selects their padding policy, this effort can be jeopardized if the server chooses to apply an ineffective padding policy to the corresponding response packets. Therefore, a client applying the "Padding" option may want to choose a DNS server that applies a padding policy on responses that is at least equally effective.

クライアントがパディングポリシーをどれほど注意深く選択しても、サーバーが対応する応答パケットに無効なパディングポリシーを適用することを選択した場合、この作業は危険にさらされる可能性があります。したがって、「パディング」オプションを適用するクライアントは、少なくとも同等に効果的なパディングポリシーを応答に適用するDNSサーバーを選択することができます。

Note that even with encryption and padding, it might be trivial to identify that the observed traffic is DNS. Also, padding does not prevent information leaks via other side channels (particularly timing information and number of query/response pairs). Countermeasures against such side channels could include injecting artificial "cover traffic" into the stream of DNS messages or delaying DNS responses by a certain amount of jitter. Such strategies are out of the scope of this document. Additionally, there is not enough theoretic analysis or experimental data available to recommend any such countermeasures.

暗号化とパディングがあっても、観測されたトラフィックがDNSであることを識別するのは簡単な場合があります。また、パディングは他のサイドチャネルを介した情報漏えい（特にタイミング情報とクエリ/応答ペアの数）を防ぎません。このようなサイドチャネルに対する対策としては、DNSメッセージのストリームに人工的な「カバートラフィック」を注入したり、DNS応答を一定量のジッターによって遅らせたりすることができます。このような戦略は、このドキュメントの範囲外です。さらに、そのような対策を推奨するのに十分な理論的分析または実験データがありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[NDSS-PADDING] Gillmor, D., "Empirical DNS Padding Policy", March 2017, <https://dns.cmrg.net/ ndss2017-dprive-empirical-DNS-traffic-size.pdf>.

[NDSS-PADDING] Gillmor、D。、「Empirical DNS Padding Policy」、2017年3月、<https://dns.cmrg.net/ ndss2017-dprive-empirical-DNS-traffic-size.pdf>。

[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>。

[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-editor.org/info/rfc7830>.

[RFC7830] Mayrhofer、A。、「The EDNS（0）Padding Option」、RFC 7830、DOI 10.17487 / RFC7830、May 2016、<https://www.rfc-editor.org/info/rfc7830>。

[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>。

7.2. Informative References

7.2. 参考引用

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。

[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.

[RFC8094] Reddy、T.、Wing、D。、およびP. Patil、「DNS over Datagram Transport Layer Security（DTLS）」、RFC 8094、DOI 10.17487 / RFC8094、2017年2月、<https：//www.rfc- editor.org/info/rfc8094>。

Appendix A. Padding Policies That Are Not Sensible

付録A.賢明ではない埋め込みポリシー

A.1. No Padding

A.1. パディングなし

In the No Padding policy, the "Padding" option is not used, and the size of the final (actually, "non-padded") message obviously exactly matches the size of the unpadded message. Even though this "non-policy" seems redundant in this list, its properties must be considered for cases in which just one of the parties (client or server) applies padding.

パディングなしポリシーでは、「パディング」オプションは使用されず、最後の（実際には「パディングされていない」）メッセージのサイズは明らかにパディングされていないメッセージのサイズと正確に一致します。この「非ポリシー」はこのリストでは冗長に見えますが、一方のパーティ（クライアントまたはサーバー）のみがパディングを適用する場合は、そのプロパティを考慮する必要があります。

Also, this policy is required when the remaining message size of the unpadded message does not allow for the "Padding" option to be included -- i.e., there are fewer than 4 octets left.

また、このポリシーは、パディングされていないメッセージの残りのメッセージサイズで「パディング」オプションを含めることが許可されていない場合、つまり、残りが4オクテット未満の場合に必要です。

Advantages: This policy requires no additional resources on the client, server, and network side.

利点：このポリシーでは、クライアント、サーバー、およびネットワーク側に追加のリソースは必要ありません。

Disadvantages: The original size of the message remains unchanged; hence, this approach provides no additional confidentiality.

欠点：メッセージの元のサイズは変更されません。したがって、このアプローチでは追加の機密性は提供されません。

The No Padding policy MUST NOT be used unless message size disallows the use of the "Padding" option.

メッセージサイズで「パディング」オプションの使用が許可されていない限り、パディングなしポリシーを使用してはなりません。

A.2. Fixed-Length Padding

A.2. 固定長パディング

In Fixed-Length Padding, a sender chooses to pad each message with a padding of constant length.

固定長パディングでは、送信者は各メッセージに一定の長さのパディングを埋め込むことを選択します。

Options: Actual length of padding

オプション：パディングの実際の長さ

Advantages: Since the padding is constant in length, this policy is very easy to implement and at least ensures that the message length diverges from the length of the original packet (even if only by a fixed value).

利点：パディングの長さは一定であるため、このポリシーは実装が非常に簡単で、少なくともメッセージ長が元のパケットの長さと異なることを保証します（たとえ固定値の場合でも）。

Disadvantage: Obviously, the amount of padding is easily discoverable from a single unencrypted message or by observing message patterns. When a public DNS server applies this policy, the length of the padding hence must be assumed to be public knowledge. Therefore, this policy is (almost) as useless as the No Padding policy described above.

短所：明らかに、パディングの量は、単一の暗号化されていないメッセージから、またはメッセージパターンを観察することによって簡単に見つけることができます。パブリックDNSサーバーがこのポリシーを適用する場合、パディングの長さはパブリックナレッジであると想定する必要があります。したがって、このポリシーは、上記のパディングなしのポリシーと（ほとんど）役に立たないものです。

The Fixed-Length Padding policy MUST NOT be used except for test applications.

固定長パディングポリシーは、テストアプリケーション以外では使用してはなりません。

Acknowledgements

謝辞

Daniel K. Gillmor performed empirical research out of which the "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman, Magnus Westerlund, Charlie Kaufman, Joe Clarke, and Meral Shirazipour performed reviews or provided substantial comments.

ダニエルK.ギルモアは、「推奨戦略」をコピーした実証研究を行いました。 Stephane BortzmeyerとHugo Conneryがテキストを提供しました。 Shane Kerr、Sara Dickinson、Paul Hoffman、Magnus Westerlund、Charlie Kaufman、Joe Clarke、およびMeral Shirazipourは、レビューを行ったか、実質的なコメントを提供しました。

Author's Address

著者のアドレス

Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9 Vienna 1010 Austria

Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9ウィーン1010オーストリア

   Email: alex.mayrhofer.ietf@gmail.com
   URI:   http://edns0-padding.org/