一般ユーザに払い出すと危険なサブドメインやメールアドレス

internet-draft 雑 Web

ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。

しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。

現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。

今回はそれを眺めていきます。

（あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。）

サブドメイン

ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)

（なお、_example のように、アンダースコアで始まるものはRFC 8552ですでにまとめられています。ここでは紹介はしません。）

  • mta-sts: RFC8461で定義される、SMTP MTA Strict Transport Securityポリシーファイルの設置に利用
  • openpgpkey: 「OpenPGP Web Key Directory」でOpenPGP certificateの参照と検証に利用
  • root-key-sentinel-is-ta-(key-tag): RFC8509で、信頼するDNSSECルートキーを示すのに利用
  • root-key-sentinel-not-ta-(key-tag): RFC8509で、信頼しないDNSSECルートキーを示すのに利用
  • www: ブラウザがWebサイトが動作していると想定して利用する

メールアドレス

ここでとりあげる文字列は、利用用途が決まってるため、メールアドレスのローカルパートとして一般ユーザに払い出すべきではありません。(例: webmaster@example.com)
(なお、大文字小文字は区別しません)

  • abuse: RFC2142で、不正利用時の連絡先として指定
  • administrator: 証明書の発行用途で利用 (CA/B Forum)
  • admin: 証明書の発行用途で利用 (CA/B Forum)
  • hostmaster: RFC2142及び、証明書の発行用途で利用 (CA/B Forum)
  • info: 証明書の発行用途で利用 (参考)
  • is: 証明書の発行用途で利用 (参考)
  • it: 証明書の発行用途で利用 (参考)
  • noc: RFC2142で、ネットワークに関する連絡先として指定
  • postmaster: RFC2142及び、証明書の発行用途で利用 (CA/B Forum)
  • root: システムの問い合わせや、証明書の発行に利用？
  • security: RFC2142で、セキュリティ関係の連絡先として指定
  • ssladministrator: 証明書の発行用途で利用(参考)
  • ssladmin: 証明書の発行用途で利用 (参考)
  • sslwebmaster: 証明書の発行用途で利用(参考)
  • sysadmin: 証明書の発行用途で利用(参考)
  • webmaster: Web関連の問い合わせ先及び、証明書の発行用途で利用 (CA/B Forum)
  • www: webmasterのエイリアスとして使用

CA Browser ForumのBaseline Requirementsは、証明書発行に関するガイドラインです。CAやクラウドサービスでも、メールアドレスベースの検証ではこれらに準拠しており、これらのメールアドレスを検証に用いてますね。

おわり

もちろん今回は仕様で利用用途が定義されているものにフォーカスしています。

他にも危険なものとかありそうだけど、まとまってるのかな？

デフォルトでCookieをオリジンに紐づける、ChromeのOrigin-Bound Cookies

cookie

Blinkの開発者メーリングリストで「Intent to Prototype: Origin-Bound Cookies」という議論が行われています。

Cookieをより安全にするために、デフォルトでCookieをオリジンに紐づけるようにする提案です。Cookieをset-cookieしたオリジン以外からは、そのCookieにアクセスできないようになります。

詳しい背景や仕組みについては次のページから確認できます。
github.com

かんたんに、Origin-Bound Cookiesの動作をみていきましょう。

例

オリジンは、スキーム、ホスト名、ポートの組です。それらのうち一つでも異なれば、オリジンが異なることになります。

例えば、次のようになります。

オプトアウト

議論されているOrigin-Bound Cookiesでは、デフォルトの動作を変更します。オリジンを超えてcookieを共有するために、オプトアウトする仕組みが提供されています。

domain属性を付与することで、オプトアウトできます。オプトアウトすることで、異なるホスト名、ポートとcookieを共有することが出来ます。ただし、異なるスキームに共有することは出来ません。

例えば、https://example.comからセットされたcookieでも「Domain=example.com」が設定されていてれば、https://example.com:1234やhttps://sub.example.comにはcookieが送信されます。ただし、スキームが異なるhttp://example.comには共有されません。

Webサイトのバグの報告先を示す contributing.txt

internet-draft 雑 Web

Webサイトのバグを見つけたとしても、その報告先を知る統一的な方法は現状ありません。

たとえば、脆弱性についてはsecurity.txt があります。https://www.facebook.com/security.txt などで使われています。
asnokaze.hatenablog.com

同様の仕組みで、contributing.txt という形式でバグの報告先を示せるようにする仕組みが提案されています。提案仕様は「a simple way to provide informations for contributors」としてIETFに提出されています。

例

contributing.txtをWebページの最上位階層に配置します (例: https://example.com/contributing.txt )

そのファイルは次の情報を含めることが出来ます。

Admin: Valentin Binotto
Bugs: bugs@vauly.net
Open Source: github.com/valentinbino
License: Creative Commons Attribution 4.0 Int. Public License
Guidelines: github.com/valentinbinotto/v434/guidelines.txt
# Valentin Binotto
# Hello, world!
  • Admin: Webサイトの管理者
  • Bugs: バグレポートを出せるメールアドレスまたはURL
  • Open Source: GithubやGitlabなどより議論するのに適切なURL
  • License: ウェブサイトのコンテンツに適応されるライセンス
  • Guidelines: このWebサイトにコントリビューションするためのガイドラインのURL
  • #~~ : コメント

ChromeのCache Transparencyに関するメモ

HTTP 雑 Web

Chromeではキャッシュの効率改善を目的とした「Cache Transparency」という仕組みが検討されているようです。

これは、「Double-keyed HTTP cache」によってキャッシュヒット率低下を緩和します

まだまだ実験を行っている段階ですが、簡単にメモとして残しておく

背景: Double-keyed HTTP cache

Double-keyed HTTP cacheは、ユーザのプライバシーを保護するために、HTTPのキャッシュをサイトごとに分離する仕組みです。

簡単な例で見ていきましょう

この時、https://cdn.exampleから読み込んだリソースをキャッシュするわけでが、同一のリソースであったとしてもa.example用とb.example用でキャッシュ領域を分けます。

こうしておかないと、a.example側はアクセスしたユーザがb.exampleにすでにアクセスしたことがあるのか、リソースの読み込み速度から類推することができしていまいます。

この時、キャッシュのキーが 『読み込んだサイト(URLバーに表示されてるURL)』+『読み込んだリソースのURL』と２つのキーになることからDouble-keyed HTTP cacheと呼ばれています。

Chromeの分析では、Double-keyed HTTP cacheによりキャッシュのヒットミスが3%増えたという分析がなされています。

Cache Transparency

Cache Transparencyは、Blink-devメーリングリストの下記のスレッドで議論されています
groups.google.com

主な目的は、Double-keyed HTTP cache導入によって上がったキャッシュのヒットミス率の低減があげられています。

その方法としては、一般に広く利用されているリソースであれば、Single-Keyキャッシュで扱ってもユーザのプライバシーには影響しないという仮説に基づいています。

"一般に広く利用されているリソース" は、Google独自の方法(Chromeのテレメトリ, クローラー)で調査され、Pervasive Payloads listとしてリスト化されます。Pervasive Payloads listには、リソースのURLとペイロードのハッシュ値が含まれ、それに一致するリソースはSingle-Keyキャッシュとして保存されます。

まだ事前の効果測定を行う段階で、実験として以下の条件を満たすリソースを対象にすることが議論されていますが。まだFixはしてなさそうです。

  • 少なくとも500のサイトに含まれる
  • 月に少なくとも1,000万回フェッチされたもの

終わりに

Double-keyed HTTP cacheによる、キャッシュミスヒット率の緩和策として出てきたCache Transparency。

まだまだ話が始まったところなのでどうなるかはわからないが、Webサイトのデベロッパーとしては、JSやCSSは共通のCDNをURLからダウンロードしたほうがお得になるかもしれない...

どうなるんだろう

NICからの割り込みを適切なCPUに振り分けるための、IPヘッダオプション

TCP 雑 internet-draft

NICからの割り込みを適切なCPUに振り分けられるようなHintをIPヘッダオプションとして定義する「Multiple Core Performance Hint Option」という提案が提出されています。（特許としても申請中とのこと）

ざっくり眺めて見ようかと思います。ここらへん詳しいわけではないので、間違いがあればご指摘ください。

背景

10Gbpsなどのトラフィックを処理する場合、NICからの割り込みを一つのCPUコアで処理しきれないことがあります。

NICからの割り込みを複数のCPUコアで分散する仕組みとして、Linuxでは「Receive Side Scaling (RSS)」、「Receive Packet Steering　(RPS)」、「Receive Flow Steering　(RFS)」などの仕組みがあります。

このとき、同じ通信フローの処理は同じコアで処理するのが好ましいです。TCPなど、処理するパケット順番が変わってしまうと、Head-of-Line-Blockingにつながります。

同一フローを同一コアに割り振るために、割り振りの方法として、送信元IP・送信先IP・送信元ポート・送信先ポートのハッシュから割当先を決める方法があるようです。


Multiple Core Performance Hint Option

先述の通り、CPUコアへの割り振りにL4の送信元ポート・送信先ポートを使用します。しかし、それらの値が取得できないケースがあります。例えば次の場合です

  • パケットがフラグメントしてる場合
  • IPSecを使用している場合

「Multiple Core Performance Hint Option」では、そのような場合でも同一の通信フローを適切に割り振れるようにIPヘッダオプションを定義します。

MCPHINT

新しいIPヘッダのオプションとして、MCPHINTを定義します。
MCPHINTはIPv4, v6ともで利用でき、2バイトのデータ領域 (Differentiation Data)を持ちます。

このDifferentiation Dataを用いてフローを識別し、CPUに割り振ることを想定しています。
（送信側がフロー毎に異なるDifferentiation Dataを格納するという仕組み）

感想

実用性がどこまであるのかちょっと実感がないが、面白い提案だなとおもった。

NIC割り込み処理の割り振り先を決定するためのヒントとして、IPヘッダにオプションを新しく定義するとは、なるほど。

QUICのマルチキャスト拡張

HTTP QUIC internet-draft

QUICを使ってマルチキャスト配信を可能にする「Multicast Extension for QUIC」という仕様が、AkamaiのJake Holland氏らによって提案されています。

マルチキャストでデータを配信することで、よりネットワーク帯域を効率用使うことが出来ます。

まだ最初の提案であり、まだTBDとなってるところもあり、これから変わりそうだが一旦目を通しておく。

背景/関連動向

まず、この「Multicast Extension for QUIC」登場と、関連状況について簡単に説明します。

AkamaiのJake Holland氏はWebでマルチキャストを使うために幅広く活動されています。今回の「Multicast Extension for QUIC」もWebでコンテンツを配信するための流れでの提案となっています。（もちろんただのQUIC拡張ですので、用途はそれに限りません）

W3Cでは「Multicast Community Group」を設立しています。
asnokaze.hatenablog.com

また、実際にブラウザ(chromiumのfork)でマルチキャストデータを受信可能にするAPIを実装していたりします。
github.com

関連仕様

関連する仕様は次のとおりです

これらに、マルチキャストでアプリケーションデータを配信するためのQUIC拡張が追加されたというながれです。

Multicast Extension for QUICの仕様

「Multicast Extension for QUIC」の仕様について眺めていきます。

ユニキャストで通常のQUICコネクションを確立した後に、マルチキャストチャネルとしてマルチキャストでデータ(1-RTTパケット)を送信できるようになります。もちろんマルチキャストチャネルはサーバ側からの一方向でしかQUICパケットを送れません。なお、マルチキャストの識別にはRFC4607で定義される(S,G)を用います。（マルチキャストルーティングについては下位層の話なので、この仕様では言及されません）

特徴としてはざっくりこんな感じ

  • QUICコネクションはRFC9000で定義された通り
  • マルチキャストデータは暗号化される(マルチキャストチャネル用の対象鍵により、他の参加者も同じデータを受信し処理できる)
  • マルチキャストチャネルのデータがパケットロスした場合は、QUICコネクション経由で再送してもらえる (なお、DATAGRAMフレームも使える)

この仕様では、拡張機能のネゴシエーション、クライアントのマルチキャストチャネルの参加/離脱、フロー制御などについて定義しています。またそのために、新しい拡張フレームやエラーコードを定義します(MC_で始まる一連の拡張フレーム)。

大まかな流れ

マルチキャストでデータ受信の大まかな流れ

  • クライアントは、QUICコネクション確立時にmulticast_client_paramsトランスポートパラメータで初期値をサーバに伝える
  • サーバは、MC_CHANNEL_ANNOUNCEフレームを送信し今存在するマルチキャストチャネルの情報をクライアントに送信します。
  • サーバは、MC_CHANNEL_JOINフレームでマルチキャストチャネルに参加を呼びかけます
  • クライアントは、サーバからの要求に対しMC_CLIENT_CHANNEL_STATEフレームを返します。MC_CLIENT_CHANNEL_STATEフレームは"参加"、"拒否"、"離脱"をサーバに伝えることが出来ます
  • クライアントは、マルチキャストチャネルでのデータ受信を開始します
  • その後サーバがMC_CHANNEL_LEAVE でクライアントに離脱を要求するか、もしくはクライアントが自発的に離脱するとマルチキャストチャネルのデータ受信が完了します
パケロス

マルチキャストチャネルのパケロスに対して、クライアントはユニキャストのQUICコネクションで再送を要求します。

MC_CHANNEL_ACKをクライアントから送ることで、パケロスしたパケットをサーバに伝えます。サーバは、ユニキャストのQUICコネクションで該当パケットのデータを再送します (QUICでは、パケロスしてもそのパケットをそのまま送り直すのではなく、再送が必要なデータのみを送ります)。

マルチキャストチャネルで受信可能なフレーム

マルチキャストチャネルで受信可能なフレームは次のとおりです。

  • PADDING Frames ([RFC9000] Section 19.1)
  • PING Frames ([RFC9000] Section 19.2)
  • RESET_STREAM Frames ([RFC9000] Section 19.4)
  • STREAM Frames ([RFC9000] Section 19.8)
  • DATAGRAM Frames (both types) ([RFC9221] Section 4)
  • PATH_CHALLENGE Frames ([RFC9000] Section 19.17)
  • MC_CHANNEL_PROPERTIES
  • MC_CHANNEL_LEAVE (however, join must come over unicast?)
  • MC_CHANNEL_INTEGRITY (not for this channel, only for another)
  • MC_STREAM_BOUNDARY_OFFSET
  • MC_CHANNEL_RETIRE

おわりに

今回はほんの一部の紹介でしたが、また機会があればフレームレベルで紹介したいと思います。

Webでのマルチキャスト配信は夢がありつつ、まだまだ熱量が高い領域ではありません。今後の動向が気になるところです。
技術的には大変おもしろいので追っていきたい。

40年越しにTCPの仕様(RFC793)が改訂される RFC9293

TCP internet-draft

2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました

TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。

この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります)

www.ietf.org

改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。

概要

この改訂版の仕様(通称 rfc793bis)は、RFC793が公開されて以来断片的に公開されたTCPに関連する追加のRFCを一つにまとめ直しています。

ですので、プロトコルとしてこの改訂により大きな変更があるわけではなく、すでに標準化されているものが整理される形になります。

例えばTCPの基本的な機能について述べた次のRFCが取り込まれます

その他にも「RFC5961 Improving TCP's Robustness to Blind In-Window Attacks」の内容を、このrfc793bisで更新します。

その他にも、すでに報告されていた仕様上のエラッタなどが修正されている他、新しく公開された輻輳制御アルゴリズム(RFC2581, RFC5681, RFC6298)など多くのドキュメントを参照するようアップデートされています。

RFC793からの変更点

rfc793bisでは「5. Changes from RFC 793」に、RFC793からの変更点がまとめられています。（先にあげたRFCの取り込みとかぶりますが、かいつまんで紹介）

  • RFC793のエラッタの修正
  • RFC1011、RFC1122、RFC6093に記載されている緊急ポインタの仕様の変更の取り込み
  • RTOの説明がRFC6298を参照するように更新
  • RFC6528の初期シーケンス番号生成アルゴリズムの取り込み
  • RFC6429で記述されるている持続的接続のリソース消費に関する考慮事項について注記
  • 輻輳制御の実装上の説明を追加