『Origin-Bound One-Time Codes』の提案仕様

雑 Web internet-draft

Apple勢から「Origin-Bound One-Time Codes」というSMSで発行するワンタイムコードのフォーマットの提案仕様がIETFに提出されています。

こちらの仕組みの標準化ということで良いかなと思います。
developer.apple.com

背景

Webのログイン時にSMSでワンタイムコードを送信し、入力させることがあります。昨今ではformの 『autocomplete="one-time-code"』属性によりユーザエージェントがSMSのコードを自動入力してくれたりします。

こちらのサイトでも書かれているように、攻撃者がフィッシングの手口で入力させたID/Passを正規サイトにインプットさせるとSMSコードを自動入力させる事ができます。
akaki.io

そこで、SMSで発行したワンタイムコードをドメインに紐付けることでこのような攻撃を防ぐのが今回の目的です

Origin-Bound One-Time Codes

「Origin-Bound One-Time Codes」ではSMSやメールで発行するワンタイムコードのフォーマットを定義しています。そこにドメイン名を追加しています。

例としては次のとおりです。747723がexample.comでのみ自動入力されます。

747723 is your ExampleCo authentication code.

@example.com #747723

おまけ

AppleおよびGoogleで実装されているようです。

SMSのワンタイムコードの自動入力が幅広く使われると便利になりますね。
まだ、IETFで議論は具体的には行われてないですが、標準化まで進むと良いなーって思いました

新しいステータスコード『420 Requester Impaired』の提案仕様

HTTP internet-draft

新しいHTTPステータスコード"420 Requester Impaired"を定義する『An HTTP Status Code to Report Requester Impairment』という提案仕様が提出されています。

これは、送信者の障害によりサーバは処理を拒否したことを示します。

目的として、重機などの機械やAIシステムが故障してることを示唆することを掲げています。提案仕様のなかでも次のように書かれています。

ある種のAIシステムは、与えられた入力に対して幻覚を見たり、不正確な答えを返したり、異なる答えを返したりといった行動を示すことがある。このようなAIが動作するスピードを考えると、人間の要求者と同様に、AIの要求者の障害を検出することも重要である。
(DeepL)

例

ステータスコードの定義なのでそのままなんですが、例としては次のとおりです
（ボディは、RFC9457 形式での応答例です）

HTTP/1.1 420 Requester Impaired
Content-Type: application/problem+json
Content-Language: en
{
    "type": "https://example.com/erratic-requests",
    "title": "Requester Impaired: Erratic Behavior Detected.",
    "detail": "Potentially dangerous and erratic requests detected."
}

おまけ

著者によると、元々のアイディアでは、リクエストを送信した人間に問題があるというエイプリルフールネタとして書いていたみたいです。しかし、AIによる現実性があるとして通常の提案仕様として提出したとのことです
( https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0239.html )

複数レコードタイプを一度に引く仕様『DNS Multiple QTYPEs』

internet-draft dns

『DNS Multiple QTYPEs』という提案仕様がIETFで議論されています。

これは、"A", "AAAA", "HTTPS"など複数のレコードタイプを一度に問い合わせする仕組みを定義しています。

背景: 複数Questionセクションは使えない

もともと、一つのパケットに複数のQuestionセクションを含めることは可能ですが、下記の理由により使用されていません

  • QNAME フィールドが複数あるので、一貫性のあるレスポンスが生成できない
  • RFC1035 などで 多くのケースで Questionセクションが単一であることを暗に述べている
  • 実装がサポートしていない

DNS Multiple QTYPEs

『DNS Multiple QTYPEs』では、EDNSオプションを使います。


  • QTD: リクエストでは0, レスポンスでは1。(エコーするサーバを検知するのに使用)
  • QTCOUNT: QT フィールドの数
  • QTn: DNS リソースレコードタイプを指定します


クライアントは

  • EDNSオプションで、QTnに問い合わせしたいレコードタイプを羅列して送信します

サーバはこのリクエストを受信した際

  • [QNAME, QTn, QCLASS]に一致するQuestionに、Answerセクションで回答します
  • サーバもAnswerセクションで回答したものを、EDNSオプションで同様にQTnを指定して応答します (これによりnegative answerを示します)

感想

Happy Eyeball v3みたいなシチュエーションで良さそうだなとは思ったが、DNSサーバ側のキャッシュ状況などによってはすべての回答を準備するのに待ちがあると思うと、準備できたものから回答してほしいかもしれないなあ

QUICのNATトラバーサル用 拡張仕様

internet-draft QUIC

IETFに「Using QUIC to traverse NATs」という提案仕様が提出されています。

このDraftでは「WebRTC over QUIC」や「P2P QUIC」のユースケースを想定しています。

大まかな流れとしては

  • 『Proxying Listener UDP in HTTP』といったProxy経由でクライアントはサーバに接続する
  • そのコネクション上でIPアドレスを交換してICE相当の処理を行う
  • QUICのPath validationの仕組みを用いてホールパンチングする
  • コネクションマイグレーションを行う

IETF 118の発表スライドがわかりやすいので、それをもって流れを説明していく

Address Discovery

QUICがProxyを経由してコネクションが確立したあと、サーバから ADD_ADDRESSフレームで候補となるIPアドレス及びポートをクライアントに送信する


Address Matching

ICEと同様にアドレスのマッチングを行う


Traversing the NAT

クライアントはPUNCH_ME_NOW フレームを使用して候補ペアをサーバに送信し、QUICのPath Validationの仕組みでパスプローブを送りホールパンチングします。
Path Validationがうまくいくと、コネクションマイグレーションの仕組みで直通信に切り替えます

QUIC通信を優先する Happy Eyeballs Version 3 の提案

HTTP QUIC 雑 internet-draft

IPv4とIPv6デュアルスタック環境において、早く通信確立できた方を使用する『Happy Eyeballs』という仕組みがあります。

「RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency」においては、次のようにAAAAレコードとAレコードの名前解決を行い早く通信確立できたものを使用するようになっています。

今回、そのVersion 3となる『Happy Eyeballs Version 3: Better Connectivity Using Concurrency』という提案仕様が提出されています。著者はAppleやGoogleの方々で、QUIC WGやTLS WGで精力的に活動されている方々です。

Happy Eyeballs Version 3

『Happy Eyeballs Version 3』の大きな特徴は、DNSのHTTPSレコードも考慮に入れて接続試行順を決めるというものです。

HTTPSレコード

まずは今回の大きなコンセプトである、HTTPSレコードの説明です。RFCにはなっていませんが「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」で定義されており、すでにブラウザやCDNで利用が開始されています。

HTTPSレコードにはHTTPSで接続するときに有用な情報が含まれています

たとえば、cloudflare.com のHTTPSレコードは次のようなデータが入っています。

"1 . alpn=h3,h2 ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5"
  • alpn: HTTP3対応情報など
  • ipv4hint: ipv4の接続先情報
  • ipv6hint: ipv6の接続先情報
  • ech: TLS Encrypted Client Helloの仕様で要求されるコンフィグ情報
大まかな流れ

Happy Eyeballsは次のような流れで行われます

  • 非同期 DNS クエリの開始
  • 解決された宛先アドレスのソート
  • 非同期接続試行の開始
  • 1 つの接続を確立し、他のすべての試行をキャンセルする
非同期 DNS クエリの開始

HTTPSレコード (SVCB / ) を送信するケースでは、次の順番で送信します

いずれかのDNSレスポンスを受け取った場合、「AAAAとHTTPS両方うけとる」「ipv6hintをもつHTTPSを受け取る」まで一定時間待ち、次のステップに進みます

解決された宛先アドレスのソート

試行する順番として、HTTPSレコードから得られた ECHやQUICサポート情報を優先的に並べることが推奨(SHOULD)されています。

その後、IPファミリとプロトコルをインタリーブさせて、リストを作成します。

接続の試行

リストに従って、順番に接続を試行していきます。（それぞれ「接続試行遅延」は通常250msecですが、最小でも100msecにするように書かれている）

コネクションの確立とは次のタイミングを指す

  • TCPであれば、TCPハンドシェイクの完了
    • なお、TLSハンドシェイク完了までをコネクション確立としてもよい
  • QUICであれば、QUICハンドシェイク完了

その他

今回のdraftには「Supporting IPv6-Only Networks with NAT64 and DNS64」といった項目も書かれているが、、、詳しい人に解説を譲ります、、、

また、個人的には「QUIC IPv6」「QUIC IPv4」の順番のがよさそうだけど、どういう順番でTCP/QUICをソートするのが良いんだろう....

今回はまだdraftが出てきたところで来月のIETF118で議論されることを楽しみにしてます。

HTTP/2 Rapid Reset攻撃に対する仕様上の対策案

HTTP internet-draft

HTTP/2のDDoS攻撃手法として『HTTP/2 Rapid Reset』(CVE-2023-44487)が世間を賑わせています。

各ベンダーから情報が出ています

このDDoS攻撃はストリームのオープン(HTTPリクエスト)とストリームのキャンセルを繰り返すことで行われます。HTTP/2では、ピアが同時に開くストリーム数を制限する事ができますが、それではオープン/クローズを繰り返す行為を制限することはできません。


（実際にはストリームのオープン/クローズは瞬時に行われる）

このHTTP/2 Rapid Reset攻撃に対して、仕様上制限することができないか？という議論がIETFのHTTP WGで開始しています。すでに「Using HTTP/3 Stream Limits in HTTP/2」がひとつの案として投げかけられています。

来月行われる IETF 118でサイドミーティングが行われるようですが、ひとまずこの提案に目を通しておく。

Using HTTP/3 Stream Limits in HTTP/2

「Using HTTP/3 Stream Limits in HTTP/2」はHTTP/3で行われるストリームオープン制限方式をHTTP/2に適応することを提案しています。

HTTP/3が使うQUICでは、"同時にストリームがオープンしてる数"で制限をするのではなく、"ストリームをオープンする回数"で制限をかけます。

実際にはストリームIDの上限値をピアに通達します。MAX_STREAMSフレームを送ることで、上限値をあげることができます。通常の利用では次のようになると思います。

ストリームIDは再利用できないので、消費された分必要に応じてMAX_STREAMSフレームを送信し、ピアが利用できるストリーム上限を上げていきますわ


ピアが高速でストリームオープン/クローズされたとしても、上限に達した場合はピアはMAX_STREAMSフレームを受け取るまでストリームをオープンすることができなくなります。

この仕組みをHTTP/2に組み込みます

MAX_STREAMSフレーム

HTTP/2のMAX_STREAMSフレームは次の形式です。

Maximum Stream Identifierによって、上限となるストリームID値を指定します。このフレームをストリーム0で送信します。

有効性について

もちろん、実世界ではこの拡張仕様 (MAX_STREAMSフレーム)をサポートしてない実装も引き続き利用されつづけるでしょう。そのような実装は変わらず 同時オープン数(SETTINGS_MAX_CONCURRENT_STREAMS) に従って振る舞うことができます。

MAX_STREAMSフレームを解釈できるピアと、できないピアにたいしてヒューリスティックに異なる制約を実装上かけることはできるかもしれない。という形にはなるのかなと思っています。ストリームの並列数はパフォーマンスにも関わるのでそちらとの兼ね合いもトレードオフが有ると思います。

DDoSは正規の処理を大量に行う行為なため制限は悩ましいですね...

なんにせよこれから議論がされていくと思うので、全く別の手法も提案されるかもしれません。引き続き議論を追っていこうと思います

TLS 1.2への新機能追加を停止する議論

TLS internet-draft

IETFに『TLS 1.2 is in Feature Freeze』という提案が出されています。

これは、標準化作業上、TLS1.2に新しい機能追加を停止しようという提案です（ただしセキュリティ対応は除く）。TLS1.2やTLS1.3にはエクステンションや、新しい暗号アルゴリズム、Supported Groupsなどを追加できるようになっていますが、それらの追加をTLS1.2では承認しないという話しです。

アプリケーションプロトコルがTLS1.2を利用することを禁止するものではありません。

議論

2023年 3月に行われた IETF 116 TLS WGのミーティングで『TLS 1.2 Deprecation (PDF)』という話しがありました。そこでは、標準化上 TLS 1.2をDeprecation する議論が行われました。

議論は、標準化上の話しと実利用の話しが色々議論されましたが、ブラウザベンダーからはTLS1.2が実際にはまだ利用されているなどのフィードバックが行われました。

その後、標準化の観点にしぼりTLS1.2への新機能停止の提案が2023年5月に提出されています。

TLS 1.2 is in Feature Freeze

『TLS 1.2 is in Feature Freeze』では先述の通り、今後TLS1.2へ新しい機能の追加を承認しないという提案です。

  • RFC8447で登録されているTLSパラメータについて、今後追加するものはTLS1.3を対象とする
    • ただし、TLS Exporter LabelsとALPNの識別子はTLS1.2でも使える
  • DTLS1.2は対象外とする

New Protocols Must Require TLS 1.3

また、あわせて「New Protocols Must Require TLS 1.3」という提案も行われています。

これは、新しいアプリケーションプロトコルはTLS1.3をサポートするよう要求する提案です。もちろん、TLS1.2の利用を禁止するものではありません。

今後

引き続き、提出された提案をもとに議論が続けられます。来月行われるIETF118のミーティング改めてWGの意見が集められるものと思います。