2025年03月31日
IETF 122
バンコクはUTC+7なのでTZ自体は参加しやすいんですが、日中は仕事があるので結局ほとんどリアルタイムでは聞けなかったという……
それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。内容の誤りなどについては責任を取りません。
moq
Agenda
今回のinteropではメディアに関するデモも追加、実施されたよう。
このmoq-wasmの中の方のscrapも参考になるのでは。
Media over QuicTransport(MOQT)動向まとめ
という訳で僕からは軽めに。全然わからないので……あと事前にagendaに記載されていた “Reducing time to first byte” は触れられてないような気がする。見落としているのかな。
Changes since IETF 121 (draft-07)
IETF 122以降、07から10での変更について。いっぱいある！07から08が一番変更が多くて、08から09ではそうでもなく、09から10は文書の位置が移動しただけ。エッジケースでの挙動が明確になったのがほとんど？
PUBLISH and SUBSCRIBE to Tracks in a Namespace
ビデオ会議で、2人目が入ってきた場合に最初に部屋にいた人の挨拶がちゃんと2人目に届くようにしたい。そういう問題を解決するための議論なんだけど、そもそも今のmoqではそれが保証できないのか？どういう理屈で保証できないんだろう。スライドにはプロトコルを理解している人にはわかりそうな図が貼られている。
Track Alias
スライドにはQuestionがあるけど、録画を見た感じでは一気に"Track Alias Alternate Proposal"まで飛ばして議論が始まっていた。pull reqがまた作られる？
MOQT QLOG
QLOGでmoqのイベントも記録できるようにするもの。今回は紹介のみで時間切れかな？
Interop report
全員が08まで実装が完了していて、10まで実装しているのが4人。08から10までの差は大きくないのでよい結果という結果。
LOC update, call for Adoption?
aboptionへの賛否に関する投票が行なわれ、賛成多数でadoptionされる流れに。
AUTH PR
MOQTにおける認証とアクセスコントロールについて。"Common Access Token (CTA-5007-A)“ という既存の標準を使うのだとか。(見るのに住所とか入れないといけなくてやだなあ、となり見れていない)
https://shop.cta.tech/products/cta-5007
"Need to create new CWT claim” とminutesにあるのはなんのことかと思えばCBOR Web Tokenのことか。この仕様を策定している団体？にもう問い合わせをしていて、結果としてはCTAを使うことは問題なくて、ただし拡張する必要はなくてCWTの定義を追加すればいいだけ(IETF内で完結できる)ということらしい。どういうものを作らないといけないのかはスライドにあるとおり(多分9ページ)。
まだadoptionできる段階じゃないのでGitHubで揉んでいこうフェーズかな。
ccwg
Agenda
5033bisがRFC 9743 (Specifying New Congestion Control Algorithms)になった 、draft-ietf-ccwg-ratelimited-increase ができた、GitHubの使い方について合意した(https://github.com/ietf-wg-ccwg )というのがIETF 121からのupdate。
HPCC++についてはagendaにあったけど時間が足りなくて取り上げられなかった。
New Tools for Testing Congestion Control and Queue Management Algorithms
agendaにあったhackathon updateっていうのは、これのことだろうか。新しい輻輳制御アルゴリズムのテストを行うツールの紹介？と結果について。ns-3上に実装されたccperfとNeSTというもの。ccperfではTCP BBRとFQ-CoDCelとFQ-PIEを、NeSTではTCP BBRをそれぞれテストしてグラフにしている。
NeSTは"a python wrapper on Linux network namespaces"とのこと。QUICのサポートについても取り組む予定とのことで、既にmerge requestは出ている。
https://gitlab.com/nitk-nest/nest/-/merge_requests/306
こういうツールがあれば輻輳制御アルゴリズムの変更を提案する人が自分達で全てのテストをしなくてよくなるので重要だ、という意見があった。
BBRv3
121から122で01から02になった。変更としては BBRIsProbingBW() の疑似コードの追加やいくつかの識別子のrenameなど。次やることはClarification、Simplification、RenoやCUBICとのより良い共存、パフォーマンスの向上、実ユースケースにおいてのパフォーマンスリグレッションの回避が挙げられてる。"Multiple deployments at scale in QUIC and TCP" や “Text both TCP and QUIC implementations can follow” などがRFC化にあたってのやるべきことのひとつに挙げられている？issueとしてはTCPでないtransportについての適応、ProbeRTTの間隔、inflight_shorttermの必要性などについて。
Rate-limited senders
前回から、投票によってwg draftになったもの。"rate-limited"が指すものについて明確にすべきだ、など文書の明確化についてが今後の課題。
SEARCH
SEARCHを実際に運用してみた結果の報告かな？HyStart、HyStart++、BBRとの比較のグラフがある。帯域がどう増加していくか、メモリ使用量はどうか、それらのテストはどのように行ったか。"Looking for volunteers to try it out!“ という点については前回と変わらず。
httpbis
Agenda
QUERY Method
Location headerに関する議論の決着がついたらWGLCに進むっぽい。
Template-Driven CONNECT for TCP
00からの更新は、non-capsule modeが削除された。終了時の扱いについてどうするかの合意ができてないので、そこが議論のポイントだったぽい。まだまだGitHub issueでの議論が続くのかな。
Security Considerations for Optimistic Use of HTTP Upgrade
GitHub上で CONNECT.*HTTP\/1.1 を含むPythonのコードを検索したところ、最初の50件のうちの少なくとも4つの異なるclientがステータスコードのチェックをしていなかった(レスポンスは待ち続けていた)とのこと。
https://httpwg.org/specs/rfc9110.html#CONNECT
RFC 9110によれば、サーバーが拒否する場合に400を返すので、無条件に成功すると見做すものではない(それはそう)。
07において明確にHTTP/1.1に対しての推奨であると記載された。ある一文においてMAYをMUSTにするかSHOULDにするかの議論が決着したらWGLCに進むぽい。
Resumable Uploads
06においては記述の大幅な変更(editorial overhaul)、expiresがmax-ageになったりとか。media-typeでapplication/partial-upload を使う際、今はPATCHだけどPUTもしくはPOSTのほうがよいか？という議論があったがPATCHで進みそう？WGLCも近そう。
Secondary Certificate Authentication of HTTP Servers
HTTPにおいて追加の証明書を使用した認証を行う方法について。耐量子暗号の証明書(という表現は正しいのか？)の場合はサイズが大きいために複数のフレームに分割せざるをえないという問題について、新しいストリームタイプを使う場合についての調査を行うことで落ち着いたよう。実装ボランティア募集中！
No-Vary-Search
スライドなし。サポートしているサイトは https://chromestatus.com/metrics/feature/timeline/popularity/4425 で確認できる。これをクライアント側として実装しているブラウザはChromeのみ。WGLCに進みそうな感じがする……
Incremental HTTP Messages
Comic Sansだなあ。シグナリングについて3つ(もしくはそれ以上)の状態を持つべきかどうか、クライアント側がincrementalいけるぜ状態をどうサーバーに伝えるか、サーバーに中間者がincrementalできるかを伝える方法はどうか、などが議論。シンプルであることがより良いという意見があり、tri-stateにはならなそう？
HTTP Unencoded Digest
例えばgzippedされたresponseを返すとき、そのdigest値を Repr-Digest で返し、gzipする前の内容のdigest値を Unencoded-Digest で返すようにするもの。range requestとかHTTP Signatureでユースケースがあるということだけど、いまいちピンと来てない……名前に関してどうするかという議論がある。
Delete-Cookie and HttpOnly Prefix
スライドなし。rfc6265bisが更新されることはないっぽい、が、rfc6265bisをさらに修正するための取り組みはあって、そっちには入る可能性がある？Shopifyの人だ！
Cookies: HTTP State Management Mechanism
スライドなし。rfc6265bisではない版のやつ。このwgでやるのが相応しいかどうかの質問で終わったか？
HTTP Client Hints Reliability
Client Hintsは最初のリクエストではサーバーが何に対応しているか不明なので最適化できず、例えば何もかもを送信するとそれはそれでプライバシーの問題がある、と。そのためにCritical-CHヘッダやACCEPT_CH frameを提案している。多くの人がmic queueに並んだようで、質疑が多い。やりとりするデータが増えることによるパフォーマンスの低下が懸念されていたり。
tls
Agenda
ECHのキャッチアップが足りなかった、というのが僕の感想です。
Encrypted Client Hello, DNS Service Bindings
Last Callになって色々なレビューがあった。ECHに関してはDNSDIRからちょっとした質問が返ってきている。svcb-echのほうは同じくDNSDIRから "I think it’s ready to go.” が返ってきている。
rfc8446bis and -rfc8447bis
これ(IETF 122)が終わったらLast Callするって！！
SSLKEYLOGFILE
IETFでやることか？というところに関して一悶着あったけど、結局は取り組みが継続されそう。一悶着あったというのは、これはメッセージ内容を復号できるのでよくない、いやいやデバッグ用のツールなので通信内容の漏洩にはならない、という議論。
rfc8773bis FATT Report
Formal Analysis Triage Team (FATT)による8773bis(External Pre-Shared Key)のレポート。果たしてPSKは量子耐性があるのか。ということで8773bisを複数の研究者にレビューしてもらった。研究者は暗号計算と記号解析の分野を研究対象としている人達で。全員がTLSに関する公開された成果がある。研究者は公開されているが、レビューコメントのどれが誰によるものかは公開されない。レビュワーに直接連絡はせず、リエゾンに対して質問やコメントを送ってほしいというお願い。
解析結果そのものは「8773bisは既存のTLSに対する脆弱性を導入するものではなく、追加の解析を行う必要もないだろう」「量子耐性については懸念事項がある」というもの。なので量子耐性に関する主張を削るか、または維持するのであればさらなる解析が必要ということに？
議論はそもそもTLS wgとして量子耐性についてどういう立場でいくべきか、という内容になっていそう。結果いくつかの投票が行われ、一番賛成票を集めたのは「TLS wgがセキュリティに関する主張を改訂するべき」という設問。
Request mTLS
クライアント側からmTLSできますよをサーバーに伝えられるようにして、認証されたbotからのアクセスを許可したいというユースケース。侃々諤々？DANEで役立つかもしれないという話が出た。
Trust Anchor IDs
*No discussion*
PAKEs
PAKE(Password Authenticated Key Exchange Extension for TLS 1.3) に関する2つのdraft。ユーザーがパスワードやPINを入力することでの認証、組み込み機器のセットアップ、ペアリング時のユースケースが提示されている。AirPlayやMiracastのときのPIN入力の画像がスライドに添付されている。
TLS wgとしてやることには賛成多数、やるならhandshakeでやるべきで、post-handshakeではないという結論になった。
Implicit ECH
ロシアでECH(Encrypted ClientHello)がブロックされてる(されてた？)のか……ECHを使うクライアントが、ECHを使っていることがわかってしまうのでプライバシー的に問題だったり、ECHを解釈できないサーバーはどう振る舞うのが正しいのか、などの問題がある。提案されているのは、ECH configとouter SNI(これなんだっけ？)が一致しない場合にサーバーは中断してはならない、outer SNIは事実上の非推奨にするなど。
ECHが普通になれば目立たなくなるのでそうなっていくべきとか、確かにこれは懸念すべき事項で、ECHは遅らせたくないがこれにも取り組むべきだ、という意見があった。これはちょっと気にしておかないといけなそうだ。
ECN public Names
IETFでは初めて見る雰囲気のスライドだ。これECHのことがわかってないとわからないな……
議論自体の結論は、ECHが完了したらやろうという感じか。
Anonymity sets in ECH
これもECHのことがわかっていないと何もわからない 😇
既存のECHのワークを中断させるものではないとのこと。
Identity Crisis in Attested TLS for Confidential Computing
Remote Attestationということで、rats wgと関連のあること？スライドの内容も、minutesに書いてあることもよくわからない……
httpapi
Agenda
HTTP Link Hints
updateがあったので確認してね、くらい？
REST API Media Types
OpenAPIのmedia typeが登録中？open issuesが2つ。次のIETF meetingまでにWGLCしたい。
RateLimit header fields for HTTP
様々なフィードバックが得られた。https://github.com/darrelmiller/ratelimiting が C# での実装。フィードバック次第では次のIETFまでにWGLCになる？
New JSON Schema
提案しているClemensさんはMicrosoftでFabric Eventstreamなどのメッセージングサービスに関するリードアーキテクトの人らしい。https://cloudevents.io/ にも関わっているのだそう。mizchiさんの言ってる「C#にうまくマッピングする水準に見える」についても、口頭でTypeScriptやJavaScript、C#、Javaへのマッピングができるように設計していると言っている、多分。
強い賛成や反対があったというよりは「とりあえずGitHub repositoryじゃなくてdraftにしてもってきてほしい」っていう結論になった感じかな？
HTTP Problem Types for Digest Fields
セキュリティ上の懸念事項(上記issue)があるのでSECDIRのレビューを受けたいという意見があった。
quic
Agenda
qlogに関しては時間がなくて軽めに。qlogの拡張をRTP over QUIC(AVTCORE)、Careful Resume(TSVWG)、MOQT(MOQ)など他wgでやってるよ。
あと、 https://github.com/quicwg/base-drafts/wiki が停滞している状況について改善する流れがあり、今はstaging環境が https://quicwg.org/staging.quicwg.github.io/ で見れるようになっている。
Multipath Extension for QUIC
11から13までの変更点は、PATH_CIDS_BLOCKED frameの追加、複数パスでのPTOにおけるガイダンス、0-RTTにおけるMP frameのエラーコードの修正、その他さまざまな明確化。draft13に対する相互運用性の確認についてもほぼ成功。
PATH_CIDS_BLOCKED frameって本当に必要？という議論に関しては、これはデバッグのために便利で、既に実装が存在するのでそのまま残すということになったのかな。次の版でWGLCになるかも。
Multipath QUICはアリババもう本番投入している？ホントに？
QUIC Address Discovery
wg draftになってますね。議事録では “Extension Negotiation” に関する質疑だけ記載されている。草案から “negotiation” という言葉を削除したと。
QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps
「遅延を正確に計測することで帯域幅の計測がより正確になる、などのモチベーション」って118のまとめのときに書いてた。他にもAckの頻度を減らすことに関しても重要。ACK frameにいくつかのtimestampに関するfieldを追加したACK_RECEIVE_TIMESTAMPS frameを使う。そもそも複数のoptional fieldを持てるようACK frameを拡張可能にするか。新しいframeを定義するか、常にtimestampを送信するようにするかという議論がある。
とりあえずdraft自体をquic wgとしてやっていくことは賛成多数だった。
Extended Key Update for QUIC
QUICのセッション中に鍵交換は1回行われる。これを draft-ietf-tls-extended-key-update をベースとして、CRYPTO streamでTLS 1.3のメッセージを送り新規の鍵交換をやる。long-lived sessionにおいて重要だと。具体的にはtelco signaling、IoT、MASQUE/VPNとかだと。
wgとしてこれに取り組むことに関しては賛成多数で可決。
Source Buffer Management
遅いネットワーク上でMacのscreen shareが重いという問題があった。ネットワークのバッファが溢れているんじゃ？という疑いがあり、実際は送信側のバッファにあったと。送信待ちのデータがめちゃくちゃ増えちゃっており、そのため TCP_NOTSENT_LOWAT が導入されてバッファの量が制限されるようになった。IETF 121のside meetingで、これはバイト数ではなくミリ秒単位の制御であるべきだという話があった。で、QUICはどうする、と。なんかメーリングリストもできてる。
各位この問題にどう対処してる？的な問い掛けのセッションってことだったのかな。IETF 123で何かしらの進捗がありそう。
QMux Formerly QUIC on Streams
QoS、言われるまで気づかなかったな……
“This will require a recharter” ということで、recharterが行われるかもしれない。
tiptop
Agenda
“Taking IP To Other Planets” の略で、惑星間通信のようなRTTがなっっっがい環境における通信では、既存のプロトコルをそのまま展開するのが難しくなるので、そのための拡張などについて議論するworking group。
唯一リアルタイムで聞けたセッション(祝日だった)。tiptopのミーティングは今回が初だったので、記念すべき1回目(？)に参加できたのはよかったです。
IP in Deep Space: Key Characteristics, Use Cases, and Requirements
そもそもtiptopで想定しているユースケースとはどんなものかについてのdraft(だと思う)。月や火星のような領域がテーマで、低軌道、中軌道、静止衛星くらいまでの地球と近い距離における通信においてはスコープ外。
通信のユースケースとしては、宇宙船などへのコマンド送信、テレメトリデータの送受信、リアルタイムメディア、一時的に通信できない場合の遅延、緊急メッセージ(救助要請とか)、科学的データ、メッセージングとか。
セキュリティやパケロスの問題についての質疑が行われていた。
An Architecture for IP in Deep Space
non-goalとして挙げられているのは、Webサーフィン、sshなどのterminal access、Facetime(などのビデオ通話？)、何かしらのインタラクティブ性が要求されるものとか。
IPv4やIPv6には変更は不要だろう。deep spaceにおいては、パケットを転送する先が存在しない場合があるので、転送可能になるまで長期間保持しておく必要があるだろうというのは確かに。UDPはそのまま使えるが、QUICはRTTが数百ミリ秒であるのが通常なので、デフォルトの構成だと宇宙には持っていけない。これに関してはシミュレーション環境において適切なパラメータのもとではQUICスタックが機能することが確認されている。TCPに関しては未調査。HTTPは、Cache-ControlやExpiresなど時間がかかわってくるheaderを使うのは適していない。などなどなど。
QUIC Simulation Results and Profile
で、そのQUICをdeep spaceにもっていく場合の話。RTTが7日間にも及ぶというのはすさまじい。長いRTTのために、initial_rtt、max_idol_timeoutなどのパラメータを調整したプロファイルの話が出ている。実験環境というのはこれ https://github.com/aochagavia/quinn-workbench かな。
Key Exchange Customization for TIPTOP
スライドの副題が “Implementing MLS inside QUIC” となっていてリアルに声が出た。QUICはセキュアな通信路の確立のためにTLSを使うけど、同期的な通信を要求する。かといって0-RTTではFoward Secrecyが低下する。そもそも非同期的に通信を行うため(？)にはContinuous Key Agreement (CKA)を行う必要があり、TLSはCKAではない。ならMLSを使おう！という提案。その発想はなかった。
MLS詳しいパーソンからの解説が待たれる……
QUIC wgにも持っていこうという話になった。TLS Extended Key Updateなら解決するのか？という点に関しては、それも依然として同期的なために根本解決ではないという返答。
その他
他にも、このwgで文章をどう編集していくかについて、GitHubでは特定の国からアクセスできない問題があるのでGitHubに依存したワークフローを採用するのが正しいのか？であるとか、使用すべきフォントは何にすべきか、自転車小屋の屋根は何色に塗るのかなどの質疑応答があった。できたばかりのwgなのでこれから色々決まっていくんでしょう。
webtrans
Agenda
2月に亡くなられたBernard Aboba氏への追悼があった。
W3C WebTransport Updateはほぼ完了、最終的には9月にW3C勧告として公開される予定。変更点はリダイレクトをネットワークエラーとして扱うようになったり、stats.atSendCapacityが追加されたりと色々。
Forward and Reverse HTTP/3 over WebTransport
WebTransport上にHTTP/3を実装する……？反応としてはこれは独自のWGでやるべきだとか、webtrans wgのcharterでは対象としてないとか、結構攻めた提案という印象。
wish
Agenda
う～～んminutesが淡白！
https://datatracker.ietf.org/doc/draft-ietf-wish-whip がAUTH48になってるという議事録が残ってるけど、今見ると https://datatracker.ietf.org/doc/rfc9725/ もうRFC 9725になってましたね。
このwgは閉じられるのか？に関しては、whepがまだあるということでもうちょっと残る？
masque
Agenda
Proxying Listener UDP in HTTP
リクエスト、レスポンスのヘッダに connect-udp-bind を使うことで、proxyのportをbindする。前回からの更新はeditorialなもののみ。実装はGoogle QUICHEがある、他の実装も探していて、実装しようと思っている人はいる。充分な相互運用性が確認できたらWGLCになりそう。
QUIC-Aware Proxying Using HTTP
Googleが実装に対して積極的だけど時間がない、次のIETFでconnect-udpと合わせてinterop testをやろうという提案があった。でも残ってるissueをcloseできたら、そのテストの前にWGLCにする予定？
Proxying Ethernet in HTTP
121からの変更点は配信できないEthernet frameに関しては、endpointはdropしなければならなくなったことと、輻輳制御によるパフォーマンスの懸念事項が追加された。相互運用のための実装募集中。WGLCしたいけど、その前にIEEEからレビューを受けるべきという意見。
DNS Configuration for Proxying IP in HTTP
これも相互運用性の確認のための実装を募集中か～。
The MASQUE Proxy
スライドの写真、良い……状況は謎だけど。MASQUEを使うとはどういうことなのか？について明らかにするための文書。Informationalだ。実際、このdraftはMLS architectureのdraftからリンクが貼られている(RFC 9750になる？)。
これが文書としてまとまってるのはいいことだけど、pearg(Privacy Enhancements and Assessments Research Group)の仕事かもしれないという意見。これに時間を割いて議論すべきか？という投票は賛成多数で可決された。
IETF 127について
IETF 127は現時点で 2026年11月14日からの開催が予定されています。
しかし、現在の米国の状況から、本当にサンフランシスコで開催するのかどうか、そしてサンフランシスコで開催された場合に現地参加できるのかどうかという懸念が高まっています。
これについては今回のPlenaryでも話題に挙がっており、1:57:28以降がそれについての議論です(多分)。ここで発言しているトランスジェンダーの方は、ドイツ政府から「あなたのパスポートで米国に入国しようとすれば、パスポートの詐称とみなされるので逮捕されるだろう」というアドバイスを受けたと述べています。
VIDEO
マジかよ……という感じですね。そしてIETF 127をサンフランシスコから別の場所で開催することを検討しているのか？という質問に対しての返答は「3/5時点では開催地の移動はしないことになっている。ただし再度議論は行われる」というものでした。財政的にも厳しいというのは、Kaigi on Railsの運営として大人数が集まる会議の場所を抑えることの難しさを知っているので十分理解できますが、しかし入国するだけで逮捕される可能性があるっていうのはちょっとなあ……
そしてこんなページができていました。
https://boycott-ietf127.org
Post by @q@glauca.space
View on Mastodon
ページを作成したのは、Plenaryで質問していたMisellさんですね。
The IETF Administration LLC has decided to continue to hold meetings in the US, in spite of significant threats to the safety of the community in traveling there. As an Internet community we strive to include everyone. Holding a meeting in the US is incompatible with our values. We call on the IETF community to refuse to travel to the 127th IETF meeting, to be held in San Francisco.
IETF Administration LLCは、米国への移動におけるコミュニティの安全に対する重大な脅威があるにもかかわらず、引き続き米国でミーティングを開催することを決定した。インターネット・コミュニティとして、私たちはすべての人を包含するよう努めています。米国で会議を開催することは、私たちの価値観と相容れない。われわれは、サンフランシスコで開催される第127回IETF会合への渡航を拒否するよう、IETFコミュニティに呼びかける。
(DeepL訳)
このページの “The US is dangerous” の項目を見れば、永住権を持っていようが拘留されうるという状況になっているのがわかります。なんなら、この声明に賛同、署名してリストに名前を載せるだけで入国拒否されても不思議ではないのかもしれません。
まとめ
毎度前回からのupdateを記載していますが、これまでの経緯なんかを自分でも参照するのが面倒になってきたので自分向けでもいいからどこかにまとめておきたくなってきました。
2025年03月09日
diff
https://github.com/unasuke/raiha/compare/1996e5495d92b67d55158182815af24320186f91…e9fad5bbedbd42212007d1005e65c23283249b15
「QUIC実装月報」と言いながら今月もTLS 1.3のことしかやっていませんが。" 39 changed files with 854 additions and 229 deletions" というのが果たして多いのか少ないのか……もっと書けたかなという気持ちはあります。
やったこと
前回のfuture workとしていた 「まずserver側の実装もして」は達成しました。自分がClientHelloを送るのに比べてOpenSSLからやってくるClientHelloに答えられるようにするには、ハードコードしていた各種値の前提が崩れてしまうので、より仕様に準拠した実装に近づける必要がありました。とはいえCipherSuiteとして TLS_AES_128_GCM_SHA256 がやってくる前提はまだ置いています。OpenSSLはデフォルトでは TLS_AES_256_GCM_SHA384 をClientHelloのCipherSuitesで一番先頭に持ってくるので、今後はそれに対応するのか、それともAlert protocolの実装を進めていくべきかは少し悩みどころです。あと、そもそもHelloRetryRequestもですね。これもまだ未対応です。
「自作実装どうしでfull handshakeを完遂できるように」については、次のようにやりとりができるようになりました。
ちゃんと暗号でのやりとりができているのではないでしょうか……
具体的には以下のようなことをやりました。
TLSのserver側としてのfull handshake flow実装( TLS_AES_128_GCM_SHA256 のみ)
シリアライズ、デシリアライズ時挙動をより仕様に準拠させた
CliehtHello内の legacy_compression_method や legacy_session_id
Record protocolの legacy_record_version
テスト用のServer実装 (SimpleServer)
TranscriptHashの導出を専用のClassに切り出し
その他リファクタリング
引き続きやっていきたいです。
2025年02月11日
happy path
趣味でQUICの実装を、そしてその前段階としてTLS 1.3の実装をしている1 ====ping==== となっているのが自分の実装から送信し、OpenSSL側で復号できたメッセージです。
勝手にhappy pathと呼んでいるのですが、CipherSuiteは TLS_AES_128_GCM_SHA256、ClientHelloに含める拡張を SupportedVersions、KeyShare、SupportedAlgorhtmsのみとしてhandshakeを開始し、client側からFinishedを送信してhandshakeが完了するまでを実装しました。
https://github.com/unasuke/raiha/tree/1996e5495d92b67d55158182815af24320186f91
「不完全」と言っているのは、RFC 8446でMUSTとされているあらゆる検証をすっ飛ばし、正しいデータしか送られてこない/送らない前提、例えばAlert protocolの実装ができていないなどの状態になっているからです。
冒頭画像において、サーバー側実装にはOpenSSL 3.3.1を使用しています。詳しくは「TLS実装のデバッグにOpenSSLが便利」 にて。
future work
まずserver側の実装もして、自作実装どうしでfull handshakeを完遂できるように、そして現時点では完璧なメッセージのやりとりがされる前提でのコードを書いているので、各やりとりでMUSTとされている検証を行い、適切なAlertを送信できるようにしないといけません。
というわけで、これから毎月くらいのペースでQUIC実装進捗日記を書けたらな、と考えています。いつまで続けられるかはわかりませんし、あまりにも進捗がなければskipする月もあるとは思います。インスパイヤ元は山本さんの「TLS 1.3 開発日記」 です。期待せずお待ちください。
2025年01月31日
今更「便利」？
趣味でQUICの実装を、そしてその前段階としてTLS 1.3の実装をしている者です。今月中にfull handshakeまで実装しようと思っていたんですが、間に合いませんでした。なのでこの記事は小ネタです。
さて本題の「OpenSSLが便利」とは今更一体何を言ってるだという感じですが、実際便利です。備忘録がてら(僕の)使い方を書いておきます。OpenSSLのバージョンは3.3.1です。
s_serverとs_client
OpenSSLには、s_clientとs_serverというコマンドがあります。TLS 1.3の実装をするにあたって、以下のようにテスト用のサーバー及びクライアントを動かすことができます。
$ openssl s_server -accept 4433 -cert tmp/server.crt -key tmp/server.key -tls1_3 -trace
$ openssl s_client -connect localhost:4433 -tls1_3 -keylogfile SSLKEYLOGFILE -CAfile tmp/server.crt
このとき、tmp/server.key 及び tmp/server.crt は自己証明書です。これを実際に実行してみると、次のような結果になります。左がs_server、右がs_clientです。
このスクリーンショットだけでも相当便利なのがわかると思います。さらに、ここで -keylogfile SSLKEYLOGFILE というオプションで SSLKEYLOGFILE を出力するようにしているため、例えば次のようなコマンドでpcapを取得していると、冒頭にも貼ったようにwiresharkでTLS Handshakeの中身をグラフィカルに見ることができます。
$ sudo tcpdump -i lo dst port 4433 or src port 4433 -w openssl_tls13.pcap
以上小ネタでした。次回の記事ではTLSのfull handshakeを(不完全ではあるものの)実装した、という報告ができればいいですね……
2024年12月27日
まとめ始めて5年目
なんとこれを書き始めてから5年目です。早いものですね。全部 yearly-wrap-upというタグ でまとめることにしました。
例年同様、冒頭の画像はwakatimeによる2024年1月1日から12月25日までのプログラミング言語使用率です。業務で触れたコードは含まれていません。やっぱり不動の1位はRuby。次がYAMLなんですが、これはKaigi on Rails 2024の公式サイトのデータソースにYAMLを使っていたり、あとはGitHub Actionsとかですね。"Other" となってるものの大半はRBSでした。
立場(毎年同様)
フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている都合上、視野が狭いかもしれません。
今年仕事で書いた記事はこれです。
AWS Lambda RuntimeをRuby3.3にしたら外部エンコーディングが変化した話 - Repro Tech Blog
プライベートだと、Kaigi on Rails 2024でも続投したconference-appにはまとまった量のコードを書いたのと、他にもGitHubのkaigionrails org以下でいくつかコードを書いて公開しています。
https://github.com/kaigionrails/conference-app/graphs/contributors?from=2024%2F01%2F01
利用した技術一覧
仕事で触れたものは覚えている範囲で書いています
Language
Ruby
TypeScript/JavaScript
Java (ちょっとだけ)
Framework
Rails
React
Tailwind CSS
Stimulus
Middleware/Infrastructure
Docker
PostgreSQL
MySQL
AWS
Cloudflare
Terraform
CI
Monitoring
OS
Editor (wakatimeによる使用時間合計順)
VS Code
Vim
IntelliJ Idea系
概念的なもの
REST API
GraphQL
PWA
QUIC/TLS
昨年からのDiffとして、Python、Kubernetes、Cを削除しました。コンテナオーケストレーションはECSしか触ってない1年だったような気がします。使用しているエディタの順は、とうとうVS Codeが1位となりました。
エディタなんですが、プライベートでは主にWindows機(たまにmacbook)を使っており、コードは家の中にあるLinux機に対してSSHして書く、というスタイルでここ数年はやっていってます。そんなスタイルだと、VS CodeのRemote SSHが本当に便利なんですよね。IntelliJ系もJetBrains Gatewayを使えば同じようなことはできるんですが、手軽さと(感覚ですが)ハマることが少ないのでもっぱらVS Codeでやってます。
新しく触れてる技術があまりなく、例年とそんなに代わり映えしないところに若干の不安を覚えなくはないです。そういうものと言われてしまえばそれまでですが。
QUIC/TLS/IETF
なんかすっかりまとめ記事を書くのが定番になったような気がしますが、始めてまだ2年目だというのがびっくりですね。
TLSについては同人誌を書くのにいっぱいっぱいだった ので実装は全然進んでおりません。あーあー。しかも同人誌は公開すると言いながらそれも全然進められていませんし。この記事を書いてる数日前からようやく実装を再開したという体たらくです。
Ruby on Rails (conference-app)
Kaigi on Rails 2024ではアプリ側のコードは大したことはやってないですが、インフラをHerokuからAWS ECSに載せかえてTerraform管理にしたり 、サイネージ(実装が雑！)をつくったりしました。
あとはまあ、お仕事は大抵Railsなので、そんな感じです。
来年頑張りたいこと
Ruby/QUIC/TLS
いい加減……実装を……はい……
Kaigi on Rails
やるぞ！！！！
……何を？(Kaigi on Rails 2025をお楽しみに)
English
今年は何度か「海外カンファレンス行かないの？」と言われたので、2025年はひとつくらい参加するのを目標にしてもいいかな？と考えてはいます。行くとしたらやっぱりRails Worldでしょうけど、被ってないとはいえKaigi on Rails 2025が近いのでどうなることやら。
2024年11月25日
IETF 121 Dublin
はい。今回はTZ的にはいわゆる仕事が終わった後に開始、というセッションが多く日本からのリモート参加も比較的しやすい回ではありましたが、Kaigi on Rails 2024のアフターイベントとか何やらとかでリアルタイム参加はひとつもできませんでした……
それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。
httpbis
Agenda
minutesがいつものHedgeDocじゃなくて https://httpwg.org/wg-materials/ietf121/minutes.html になっているのはなにゆえ……？
Resumable Uploads
05での更新はUpload-Lengthヘッダの追加など。次やることは文書の整理、実装の最新draftへの追従、相互運用性のテスト、本番環境での運用経験を得ること。クライアント側実装はSwiftとObjective-C(というかiOS用のライブラリ)、JavaScript。サーバー側実装はSwift、Go、.NETの3つ。
ハッカソンにおいて相互運用性のテストが行われ、全ての実装が最新のdraftに追従、試験もたくさん成功したとのこと。
https://wiki.ietf.org/en/meeting/121/hackathon#resumable-uploads-for-http-rufh
アップロードの進捗を取得するために1xx status codeを使うことについての議論があった。もしかしたら現在未使用の104が割り当てられるかもしれない？
QUERY Method
120からの主要なupdateとして、Content-Location ヘッダと Location ヘッダの用途についてとそれに設定するURIのガイダンス、Accept-QueryヘッダのIANAへの登録が挙げられている。議事録にはAccept-Queryの値に対してStructued Field Valuesは使わないでくれ、くらいしか記載がない。
Cache Groups
スライドがない。とはいえIn WG Last Callだし、もう特に議論すべきこともない段階？
Incremental HTTP Messages
last updatedが10/15で新しい、奥さん(連名)のdraft。
This document specifies the “Incremental” HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally.
abstractを読むとやはりCDNベンダっぽい課題感だなと感じる(とはいえ連名はFastly, Apple, Mozillaだけど)。HeaderにIncremental を指定することで、通信の中継者が全てのメッセージをクライアントから受信する前に背後(クライアント)に渡し始められる。これによって最終的にクライアントがタイムアウトとなる前にサーバーからのレスポンスを返せるようになる(例としてserver side events)……ってことかなあ。
スライドのmemeっぷりたるや。incremental enthusiastが多めで前向きな感じがする。
The HTTP Wrap Up Capsule
“GOAWAY is a sledgehammer”
00 → 01でIntroductionが大幅に加筆された。WRAP_UPによって、(MASQUEの例として)あるclientがCONNECT-UDPとCONNECT-TCP(あるいは別のproxy connection)の2つの接続を互いに別々のoriginに、単一のproxyを介して接続しているとき、CONNECT-UDPのほうでGOAWAYが起こると全部のconnectionが突然に終了されてしまう問題を解決できる。proxyの側がWRAP_UPをclientに送信することでclientがgracefullyにconnectionをdrainできる。client側からWRAP_UPを送信することを可能にするか？という議題がある。前進しそう。
Guidance for HTTP Capsule Protocol Extensibility
Capsuleプロトコルについては以下。
RFC 9297をupdateするもの。RFC 9297のwgはmasqueだけど、このdraftはhttpbisの議題になっている。capsuleの拡張性について。
Endpoints that receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule and skip over it to parse the next Capsule.
という文書における “endpoint” が一体何であるかが曖昧、というのを出発点にしている。proxyは含まれるのか、とか。
結論としてはもうすこし議論しようということっぽい。
Cookie eviction
Delete-Cookie ヘッダーで明示的にCookieを削除できるようにする？
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ がちゃんとRFCになってから取り掛かるのでいいのでは？という意見があった。
AD-Requested Feedback (draft-ietf-netconf-http-client-server)
YANG（ヤン、英: Yet Another Next Generation）は、データモデル言語の一種である。NETCONF や RESTCONF などのネットワーク管理用プロトコルによりアクセスされるネットワーク機器の設定や状態、遠隔手続き呼出し (RPC)、通知をモデル化するために開発された。
https://ja.wikipedia.org/wiki/YANG
netconf wgのdraftについてhttpbis wgからのフィードバックはあるか、というやつかな。肯定的ではあるものの、もっと議論が必要という感じ。
Template-Driven CONNECT for TCP
MASQUE for TCPってスライドには書いてるし、そういうものを実現するためのもの？
HTTPの拡張CONNECTメソッド について復習する - ASnoKaze blog で connect-upd を使うという解説があるけど、こっちは TCPの上に載せるのでconnect-tcp を新しく定義して使うとある。
Capsuleを使うべきでは？という意見がいくつか。賛否両論で、さらに議論しようという結論。
Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
もともと “Security Considerations for Optimistic Use of HTTP Upgrade” という名前だったのが後半が “Protocol Transitions in HTTP/1.1” に変更されている。
101(Switching Protocols) が返ってきた場合やCONNECT methodを使用する場合に使用されるプロトコルが変わることがあり、その場合におけるセキュリティ上の問題を解決するためのもの。Proxying UDP in HTTP" (RFC 9298)を更新するとも。
https://datatracker.ietf.org/doc/rfc9298/
スライドには120以降の変更についてと、HTTP CONNECTについて新規に追加された記載についてしか書いてないな？実際最終段階らしく、last callに向けてもっとreviewしようという感じで終わっている。
No-Vary-Search
No-Vary-Search というヘッダーで、URLのparamsに入っているものがレスポンスに影響するかどうかを知らせることができるようになる。なのでparamsのバリエーションによるキャッシュのうんぬんを制御できるってことだろうか。既にChromeにはサポートが入っているっぽい？call for adoptionされそう。
上記は前回の自分のblogより。
スライドで「CG Draft」にsuspendedとなっているのは、WICGでの策定？はやめて、httpbis wgでの作業に一本化したということ？なのか？
Editorial: Move No-Vary-Search to IETF HTTPbis by jeremyroman · Pull Request #338 · WICG/nav-speculation
IP Geolocation & HTTP
いわゆるGeoIPの話。間に中間者を挟むなどで自分のIP addrは知られたくないが、地理情報は伝えたい(？)ケースがある。そのときに Sec-CH-IP-Geo で地理情報をサーバーに送信できるようにする提案。目的としてはIP addrによる地理情報の推測をやめていきたい、というものだとか。問題意識はわかるような……とりあえず継続して議論しようというステータス。
moq
この章を書いている途中で 第2回 Media over QUIC とか勉強会 - moq-wasm 開発秘話!!【Media over QUIC とか勉強会】 | 高田馬場 Live Cafe mono に参加し、nttcom/moq-wasm を実装している方々とお話しすることができました。なので色々なワケワカラナイだった部分がだいぶわかるようになりました。やっぱ実装してるとより理解が進むし、実装しなければわからないこともあるということで。
Agenda
IETF 120からinterim meetingsが12も実施されている。やば。そしてこの記事を書いてる間にもどんどんinterimが予定されていって、今ではこうなっている。
https://quic.video/blog/transfork/ が気になってるけど、議題にはないのかな？まあないか……
Interop
一番実装が進んでいるものでも 6 (unsubscribe) までで、7 (goaway) を実装できているものはない。そもそもinteropの内容が120から変わっていなかった、という話も(前述のスライドで)ありましたね。
MoQT Updates Since Vancouver
IETF 120以降でMoQ Transportに入った変更まとめ。超interimがあったので、こういうのがあるのが本当に助かる……そしてまあ、いっぱいありますね。
JOIN
複数のgroupにobjectが配置されている場合においてRTTを削減できるってことか？beneftとしてスライド内で説明されているのが以下。例えば解像度の切り替えなんかで嬉しいというように読める。議事録によると、スライドにあるproposal #2が賛成多数ということでその方向で進むらしい。
スライド読んで！
Updating MoQT Priorities based on Implementation Experience
priorityについての記述のあいまいさがあるみたいで、そのための議論のよう。複数のgroup間でのpriorityの順序がどうなるか、ということっぽい。これもproposalが2つ挙げられており、決を取ったところproposal 2が賛成多数となった。proposal 2はsubgroup内でuniqueなpriority値をつける方式。見た感じgroupにもまたがっていそうだけど……？
スライド読んで！！
Process / Workflow
moq wgのプロセス及びワークフローについて。chairがコンセンサスを確認できていない、virtual interimで物事が進んでいて参加できない人がおいていかれる、運営が難しいという問題が挙げられている。いくつかの解決策が挙げられていて、議事録を見た感じではそれで合意した……？
WARP + Catalog Merge
なんか色々ある……まず、10月のinterimにおいて、CatalogについてはWARPにmergeし、個別のdraftにはしない。interopはメディアストリーミングフォーマットに焦点をあてる。この2つがCatalog design teamのsummaryとして合意を得られている。
interopに関するInformationalなdraft (MOQ-MI)も作成されている。
https://datatracker.ietf.org/doc/draft-cenzano-moq-media-interop/
WARPとMOQ-MIでサポートしている機能が異なることについての議論がされたっぽいけど、議事録は簡潔すぎてちょっとわからない。Core featureとして最低限どこまでサポートするべきか、みたいなところが今後のワークで明確になる？
スライド読んで！！！
SWITCH
解像度を変えるなどしたい場合に、新しいgroupを受信しても今ある解像度から新しい解像度とのgroupの間のobject(？)をもらわないといけないとき、SUBSCRIBE+UNSUBSCRIBEか、それにFETCHもまざってくるかというケースの複雑さを解決するために導入する仕組みがSWITCH。具体的にどうするかについてはこれからっぽい。
スライド読んで！！！！
Timestamps
Delivery TimeoutとMax Cache Durationが相対的でありベストエフォートである。もしパケロスや順序の入れ替わりがある場合にskewedとなる。エンコードに時間がかかるケースにおいてはcaches upできない？？optionalな"timestamp"を導入することで解決するということらしいが。わかりません！
STOMP
latencyの計測のためにmoqt上で時刻のmetadataを交換できるようにするっぽい。地理情報も含められるようになっている。しかし事情によりskipとなった。
ccwg
Agenda
recharterするっぽい？その兼ね合いでテストスイートがあると嬉しい、古くならないよう長期的にメンテされているべきだ、みたいな話がされていた。これ、Hackathonと関係していそうだけど。ns-3っていうやつが便利なツールっぽい。
https://www.nsnam.org
なんか日本の大学の名前が見える……
Hackathon Update
なんかあったらしい。"Design a suite of test cases based on 5033bis, the proposed new BCP on Specifying New Congestion Control Algorithms" は超ステキだと思うが。成果は……どこにまとまってるんだろう？？？
BBRv3
変更点としては、wg draftになっているとか、元文書がXMLからMarkdownになっているとか、明確化したとかとか。軽微なアルゴリズムの変更をするpull reqが2つopenになっていて、TCPでないtransport(主にQUICのことを指してる)に対する一般化についてのissueがopenになっている。
SEARCH
現実世界でのdeployに協力してくれるボランティアを募集している段階？ccwgのワークとして取り組むことに賛成の意見が多いので、引き続きなにかしら行われそう。
Increase of the Congestion Window when the Sender is Rate-Limited
送信者のデータ送信がrate limitedな場合における輻輳ウィンドウの増加について……？この挙動について、十分な送信が行われていない場合には輻輳ウィンドウの増加に制限をかけるようにする提案。"Who thinks we should not do work on this topic" が0 votesなので、肯定的な反応。
が、前回。これも投票の結果、ccwgのワークとして取り組むことに前向き。
SCReAMv2
スライドの最後がオシャレ。ccwgのワークとして取り組むことの賛成は反対より多かったけど、no opinionを含めてあまり差がない感じ。どうなるんだろう？
他のものについては時間切れ。
wish
Agenda
こんなwgありましたっけ……？って思ったけどpast meetingsは110からあって完全に節穴でしたね。
WebRTC Ingest Signaling over HTTPSなのでWHIP/WHEPのwg。
WebRTC のシグナリング規格 WHIP と WHEP について が概要をつかむのにはわかりやすいかも。
WebRTC-HTTP Egress Protocol (WHEP)
agendaはこれだけ。そしてin WG Last Call状態。行われた議論自体はGitHubで未解決のissueについてとWHEPについて。WHEPはURLをどうするかについてどうしようか状態なのと、失敗(何に？)した場合の振る舞いについて定義しないといけない、ということについての議論があった。minutesを読むと議論があったことはわかるけど結論は書かれていなくて、合意に至らなかったのかな。
quic
Agenda
Multipath QUIC
10から11の変更点は4-tuple addressがhas already been validatedな場合にendpointがchallenge(とは何だ)なしでpacketをsendできるようになった、PATH_ABANDON frameのerror codeについての再定義とreason phaseの削除、最大path identifierに達したことを通知するPATHS_BLOCKED frameの追加、transport parameterの変更といったところ。hackathonでのinterop testの結果報告も。
話し合われたissueは4つ。issue 459はendpointがCIDを有効な各Path IDに対して発行しなかった場合どうなるかについて。現在のdraftにおいてはpeerが新規pathを開いたらCIDを発行するのがRECOMMENDED。 ただしMAX_PATH_IDがnegotiateされるまではPATH_NEW_CIDを送ることができないので、遅延させたい。合意に至らず。
issue 414はPath Abandonのerror codeについて。UNSTABLE_INTERFACEやNO_CID_AVAILABLEのようなものが必要か？という話。新規にpull reqを作成して議論するみたい。
issue 457はPTO handlingについて。ある1つのpathにendopointがpacketを送り、突然そのpathがブラックホールになった場合(つまりpacketが虚空に消えた場合か？)の挙動かな。RFC 9002に従えば、endpointはackがそのpathから戻されない場合、PTOが発生するまでそのpacketが失われたと見做されない。議論の結果、何らかの指針を追加することが決まったみたい。
issue 458はmultipathがnegotiatedな場合においてPath migrationかnew pathのどちらをすべきかについて。endpointは通信内容を送信するために新規4-tuple addressを使いたい。新規pathを作成するのがREDOMMENDEDとなっている。ここの内容、どういうことなんだ……
WG last callになるかどうかについては、もう一回改訂を重ねるということになった。そもそもやろうとしてることが多くて大変とも。
qlog
なんだこのbikeshedは(スライドp6)。qlog-main-schemaについては09で識別子の名前が変更されたりなんだり。
JSON-SEQがpainfulであるというbikeshedについて。JSON-SEQが何かというとRFC 7464 のことらしい。今はJSON-SEQを使うこともできる、という状態(application/qlog+json-seq で返す)。他にもNDJSONやJSON linesという選択肢もある。JSON-SEQを使う場合、grep、vimとの相性が悪く、またjqで使うには --seq optionを渡す必要がある。それらを踏まえてJSON-SEQのままでいくか、他の何かを採用するか、それとも他のserialization formatを追加するか、何のstreaming serialization formatも推奨しないかのどれにするかという議論。結論は出なくて、年内のWGLCに向けて解決しないといけない、というところで終了。
Address Discovery
P2Pな状況におけるQUICにおいてpublic addressを検出、シグナリングするための拡張。そもそもquic wgとして取り組むべきかどうかについての投票が行われ、賛成多数。
Flexicast QUIC
The deployment of QUIC opens an interesting opportunity to reconsider the utilization of IP Multicast. As QUIC runs above UDP, it could easily use IP multicast to deliver information along multicast trees. Multicast extensions to QUIC have already been proposed in [I-D.pardue-quic-http-mcast] and [I-D.jholland-quic-multicast-05]. To our knowledge, these extensions have not been fully implemented and deployed.Flexicast QUIC takes a different approach. Instead of extending QUIC [QUIC-TRANSPORT], Flexicast QUIC extends Multipath QUIC [MULTIPATH-QUIC]. Multipath QUIC already includes several features that are very useful to allow a QUIC connection to use unicast and multicast simultaneously.
おお……？unicastについてはbidirectionalなpathを使い、multicastについてはshared unidirectional flowを使う？(p4の図)
フィードバック求む！状態。
httpapi
Agenda
HTTP Privacy
httpなpathにrequestをした場合、httpsへと301 redirectするというのはありふれている。このとき最初のnon-secureなrequestにapi keyなどのcredentialが含まれているとunsecureだよね、という話。このdraftはBest Current Practiceなやつ。serverおよびclientに最初からsecureな通信での開始を行うための指針を提供するもの。HSTSとかHTTPS DNS recordとか。
HTTP Signature
なぜスライドにこんなに映画ネタを……？ https://httpsig.org/ を今さら見て気付いたけど、Ruby gemとして https://github.com/nomadium/linzer というのができているのか。これはRFC準拠っぽい。
Digest FIelds Problem Types
RFC 9530 のDigest Fieldでdigestが不正だった場合に、RFC 9457 の仕組みを用いて結果を返すためのschemaを定義するものかな？
oracle attackに注意というコメントがあった。
REST API Media Types
OpenAPIやJSON Schemaをresponseとして返せるようにするもの。レビューしてlast callの準備ができたか確認するということになった。
RateLimit header
そういえばRate limitの仕組みがRailsに入ったよな……
patition keyが入った？のかな、これは便利という意見があった。
masque
Agenda
いつ見てもなんかSEGAを彷彿とさせる。
QUIC-Aware Proxying
04での更新点は、Proxyはoriginal CIDsに限定した(as long asをこう理解していいのか？)virtual CIDsをpickしないといけない、MAX_CONNECTION_IDSをproxyに登録されるconnection idsの上限を限定するために追加した、など。スライドにある議題として、issue 113のPreferred address migrationについては追加の議論はなかった。issue 115のActive attack on scramble transformが主な議論。active attackerはiv生成のために使われるバイト列を複数のpacket間で共通になるように変更できる。packetそのものは無効または破棄されるけど、scrambled packetには一致するバイト列が含まれており、プロキシの両側のフローを対応することができる、と……結論としてはこのような攻撃手法がある、という対応のみに留まりそう。
Proxying Linstener UDP in HTTP
前回(っていうのは120のこと？)からの変更は特になく、WGLCになるまでに相互運用性があると嬉しいので、実装に意欲的な人を募集中、という段階。hackathonで1つ実装した、という話があった。Googleによるもの。それってこれのことなのかな？ https://github.com/google/quiche/commit/29f785f59dfb33f4fff4c87852983c2cb7808ad0
Proxying Ethenet in HTTP
hachathonでericsson clientとgoogle serverとのinteropが行われたとのこと。もっと他の実装も募集中。輻輳制御に関して未解決の問題が残っている。これについてどうすべきかはまだまだ議論が必要という感じになっている。
DNS Configuration for Proxying IP in HTTP
dnsop wgに持っていって早期レビューを受ける流れ？
tls
Agenda
会場めっちゃ広くない？？？？？
あとIETF 121が終わってからML-DSA がめっちゃもりあがってる んだが……
Trust Tussle Interim Summary
Avoid client trust conflicts by enabling servers to reliably and efficiently support clients with diverse trust anchor lists, particularly in larger PKIs where the existing certificate_authorities extension is not viable.
たぶんinterimの議事録をもっとちゃんと読めばどういうものかわかりそうなのであとで読むかも……
https://datatracker.ietf.org/meeting/interim-2024-tls-01/session/tls
ステータスとしては、もうひとつdraftが来るという。
TLS Registries Update
TLS Registyに入った変更について。"A stunning presentation.“
ECH Discussion
issueについて議論する回。AD reviewでついたDNSの問題については、合意に至らずADからの勧告があれば従うと。他にもいくつかあるopen issueについての議論が行われた。今repoを見てる感じでは、それらに対応した変更がcommitされていそう。
FATT Updates
FATTの現状について。議論は公開されるべきだ、という意見が多い。(動画だと結構長い時間話してたけどmisnutesがアッサリめ)
DTLS Clarifications
RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 の改訂が必要だ、という1枚目から始まる。TLS 1.3とDTLS 1.3でKeyUpdatesの適用タイミングが異なるとか(マジで？)、1.3でしか対応していないACKがversionをまたいで使われる場合の挙動とか、Epoch managementが明記されていないとか、とか、とか……結構ございますわね。
repositoryを作るよ、という話になったぽい。
Abridged Certs Update
certificateの圧縮。pass 2は複雑(これ2パス圧縮のことでいいのかな？)なので辞書なしのBrotilを使おうという提案がある、と。よりシンプルになるが圧縮率は落ちる。それはそれとしてZstdとBrotilのどっちでいくかはまだ議論中かな？
Extended Key Update
ExtendedKeyUpdateRequestを受信したときにalert & terminateしていたのがExtendedKeyUpdateResponseを返すように定義されたり、ExtendedなKey Updateが実行されたときにSSLKEYLOGFILEにどう記録するか、などの更新。未解決issueはもうない！
SSLKeylog ECH
最新のWiresharkではもうサポートされている！！
まとめ
アー
2024年10月29日
感謝
Kaigi on Rails 2024に参加していただいたみなさま、ありがとうございました。登壇者の皆様、Proposalを出してくださった皆様、協賛してくださった企業の皆様、そして一般参加者の皆様のご協力のおかげでKaigi on Rails 2024を終えることができました。今年もハイブリッド開催となりました。2年目そして2回目ではありますが、いかがだったでしょうか。
以下、手短にふりかえっていきます。
インタビュー
まさかのFindyさんにインタビューをしていただけることになりました。
コロナ禍・逆境からの立ち上げを経て、人気カンファレンスへ。Kaigi on Rails運営の裏側 - Findy Engineer Lab
いやはや、なんとまあ……まさかインタビューをされる側になるとは思いませんでした。
conference-app
せっかくv8.0.0.beta1が出たばかりなのだし、思いきってconference-appも v8.0.0.beta1 に上げてみました 。また、SidekiqからSolid Queue + Mission Control Jobsへの移行もしています 。他にもRailsに関係しないところだと、HerokuからAWS App Runnerに乗せかえました。参加者の皆さんから見れる機能としてはあまり変化はしていませんが、裏側は色々と変わっていたのでした。
ただ、deploy後に放置しているとrequestがtimeoutするという現象が発生しており、ご迷惑をおかけしました。原因は謎1
せっかくなので、会期中のmetricsを出しておきます。
リクエスト数が跳ねてるのがオープニングのタイミングですね。みんながスクリーン上のQRコードを読んだのがそれだと思います。
オープニング
なんとオープニングの挨拶をすることになってしまいました。初日の一発目ということもあり、ハイテンションで元気良くを心掛けた結果、皆さんから「元気があってよかった」「高専の寮生の挨拶かよ」などと好評だったようでよかったです。
2025
とうとう今年はクロージングで来年の会場と日程を発表できましたね。「成長」を感じます。
スタッフはまだまだKaigi on Rails 2024の作業が残っているので気持ちが2024のままなのですが、今回参加していただいた皆さんの高まった気持ちをKaigi on Rails 2025がちゃんと受け止められるよう頑張っていきたいと思います。
2024年09月30日
再始動(再)
https://unasuke.fm を公開しました。ロゴは衰咲ふち(@otoroesaki) さんに作成していただきました。この場を借りてお礼申しあげます。ありがとうございます。
一旦は今までのエピソードを聞けるようにしただけ になります。今後、エピソードごとのサマリやshownoteの記載、RSS feedの公開などの改善を進めていきます。
加えて、次の収録についても日程含め検討中になります。
……と、unasuke.fmの再始動 で書きました。結局、その後長い間新規のエピソードの公開はできていませんでした。
ですがなんやかんやあり、2024年07月06にosyoyuさんとの回 を、続けて07月14日にsylph01さんとの回 を公開することができました。
podcast platforms
ついでにRSSの準備と、Apple Podcast及びSpotify Podcastでの公開をしました。
説明がおざなりなのはまあ、はい……あとでなんとかします。unasuke.fm上にもそのうちリンクを置きます。
公開が遅くなることへの言い訳
さて、大倉さんが始めたOH! MY RUBYISTS を聞いた人はもうご存じかと思いますが。大倉さんとの回をもう収録済みです。で、それがまだ公開できてないわけですが……
episode 8からですが、transcriptionを用意することにしました。単純にその書き起こしを準備するのに時間がかかっているためです。なぜ書き起こしを用意するかというと、自分が音声を聞くより文章を読むほうが頭に入りやすいからです。Podcastをやっておいて何を言っているんだという感じではありますが……
次々回以降
当人には伝えていませんが、候補にしている人は2人ほどいるので、再開したと言いましたが引き続き期待せずお待ちいただければと思います。
2024年08月21日
IETF 120 Vancouver
前回の続きです。
前回 → IETF 120 Vancouverにリモート参加しました
参加したセッション
例によって、以下常体と敬体が入り乱れます。
httpbis
mozaic.fmの方々による復習がX上で行われていたので、そちらを参考してもらうほうがいいような気がしますが……一応自分でもまとめます。
Agenda
https://datatracker.ietf.org/meeting/120/session/httpbis
Resumable Uploads
再開可能なアップロード。HTTPで再開可能なアップロードを可能にする提案仕様 - ASnoKaze blog
minutesによると大まかな議題は3つで、Upload-Limitはproxyとorigin serverのどちらによってセットされるのか、Upload size、サーバーからのdigestのリクエストについて。
QUERY
特に資料はなし、expired & archivedになってるけど……
“weather in Vancouver” という検索をした場合に返却されるのは現在の天気へのリンクか、これまでの天気をリストしてあるページへのリンクかという議題と、Cacheについての議題。質問した人はdraftのautherになるべきだろうという結論になっている。
Cache Group
openなissueがないのでReady for last callとのこと。実装が無い？というところが気になるけど、既存のコードとの互換性がある(？)のでいいのでは、ということになっている？
Communicating Proxy Configs in Provisioning Domains
httpbisではなくintareaからのもの。Motivationとしてはモダンなproxy typeの探索、既存のシンプルなproxy設定との共存、PACファイル、WPADへの依存をなくす、とあるけどこれは何……？
なるほど。で、それらに依存しない方法として、Provisioning Domain(PvD) JSON format に対してproxyのサポートを追加しようというもの。提案しているのはAppleの人とMicrosoftの人。Private Relayが関連している可能性がありそう。資料では、 /.well-known/pvd に対してGETすることを想定している。認証についてや、クライアント証明書についての設定がどうなるかについての疑問が出ている。
Security Considerations for Optimistic Use of HTTP Upgrade
https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/
* https://datatracker.ietf.org/meeting/120/materials/slides-120-httpbis-sessa-security-considerations-for-optimistic-upgrade-00
* https://github.com/httpwg/http-extensions/labels/optimistic-upgrade
https://http.dev/ というサイトがあるんですねえ。openなissueについての議論が行われた様子。
Secondary Certificate Authentication of HTTP servers
HTTPレイヤで追加のサーバ証明書を送信する Secondary Certificate の仕様について - ASnoKaze blog
なるほど……議論としては証明書のサイズの問題に関すること以外はちょっとわからない。
The HTTP Wrap Up Capsule
Privacy Proxy(Priovate Relayみたいなの？)においてlong-livingなstreamを終了したいが、ブラウザからはリクエストが処理されたかどうか不明な場合にはそのリクエストを再試行できない。クライアントがあるstreamにおけるリクエストを中断して別のstreamもしくはconnectionに対して新しいリクエストを送信できるように、proxyのような仲介者が実際の終了が行われる前にそろそろ終了する通知を送るようにできるのが最善。なので、proxyがそのconnectionで新規のリクエストを開始すべきでないと通知し、既存のリクエストの終了を可能にする WRAP_UP カプセルの提案。(abstractの要約)
GOAWAYではなく？という質問に対して、GOAWAYはproxy自体がいなくなることを表し、これはリクエストごとに対する通知になるという返答があった、くらいしか読み取れず。webtransportに似たような提案がある？
HTTP No-Vary-Search
No-Vary-Search というヘッダーで、URLのparamsに入っているものがレスポンスに影響するかどうかを知らせることができるようになる。なのでparamsのバリエーションによるキャッシュのうんぬんを制御できるってことだろうか。既にChromeにはサポートが入っているっぽい？call for adoptionされそう。
Revising Cookies
“Yet another cookie spec revision! But why?!”
Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog 既にある6265bisではなぜいけないのか。それは “cookie store"の概念を明確に定義したいからだ、Webブラウザ以外のagent(例えばcurlとか？)がどのようにcookieを扱うかを定義するためだ、と。6265bisの編集者から好意的に受け止められている。
Versioning for HTTP Resources
あるリソースを共同編集している場合や、Gitリポジトリのホスティングなどにおいて、リソースのバージョンとその祖先についての情報をリクエストヘッダに付与することでなんかいろいろできるようにしようという提案。最終的に目指すところまでには4つの提案が必要と言ってて、これはその最初の1つらしい。す、すごい。もっと議論が必要というところで終わっている。
httpapi
Agenda
https://datatracker.ietf.org/meeting/120/session/httpapi
スライドはほぼない感じ。大部分はChair slideに書いてあるのかな。
https://datatracker.ietf.org/meeting/120/materials/slides-120-httpapi-chair-slides-00
The Idempotency-Key HTTP Header Field
まだまだ議論中という感じ。8月末までに合意が得られるようにしたいとのこと。
Link relationship types for authentication
SECDIRからの早期レビューを受けたとのこと。
HTTP Link Hints
いくつかの未解決issueがあるが、それを話す人がいない。
Byte Range PATCH
byterangeと言いつつ、単位がbyte以外のユースケースが出てきている……？あとgzipされている場合に展開されているほうなのか圧縮後のほうなのか、だとか。言及されているhttpbisの "bride” っていうのはこれかな？
https://datatracker.ietf.org/doc/draft-toomim-httpbis-braid-http/
Internet-Draftの冒頭がこんなことになってるのは初めて見た(是非見てみてほしい)。(あれ、これってVersioningのやつでは……？)
RateLimit header fields for HTTP
以前のdraftからの更新点の共有とフィードバックくださいという報告かな。unit と scope が追加された。
REST API Media Types
“openapi+json” や “openapi+yaml” をどうするかについて議論中。
HTTP Problem Types for Digest Fields
今回出てきた新しいinternet-draft。RFC 9530 Digest Fields ではContent-DigestやRepr-Digestなどのヘッダを定義して内容および表現の完全性を保証する仕組みがあり、しかし完全性に関連するエラーを通知する方法の標準がないことを解決するためのもの。興味深い。他にもそういった、問題が発生したときにそれを通知する標準がないものはいくつかあるらしい。
masque
Agenda
https://datatracker.ietf.org/meeting/120/session/masque
QUIC-Aware Proxying Using HTTP
そもそもは、RFC 9208: Proxying UDP in HTTP を用いてQUICに最適化したProxyを可能にするためのドラフト。これどういうことをしたいのかちゃんと理解しておきたいな……
議題は「Preferred address migration」、「Limiting CID registrations」、「Client VCID length」の3つかな。それぞれ、再接続でいいのでは、制限に到達したらフロー制御を行う、同じかそれより長くする必要がある……という結論になったように見える。
Proxying Bound UDP in HTTP
やりたいことは、1つのProxyに対するconenctionで複数のtargetsに対する接続を行うこと？例えばRFC 9208だとWebRTCでICEをしたい場合などがサポートされていない。
connect-udp-bind というheaderを付けることで使用を宣言する。
相互運用性がどうなのか、というのの確認段階に進んだみたい。
Proxying Ethernet in HTTP
Ethernet framesをproxyするためのdraft。これが可能になると追加のencapsulationによるadditional MTU costが削減できるという利点がある？
VLAN tagging、Ethernet versionのサポート範囲、レイヤー分離と輻輳制御などについてのopen issueがあり、それらについての議論が行われた。実装はまだないのかな？実装したい人は教えてね、というログがあった。
DNS Configuration for Proxying IP in HTTP
RFC 9208ではHTTP load balancersを介したVPNを構築できるが、DNSに関する構成情報を交換することができない。ので、RFC 9297: HTTP Datagrams and the Capsule Protocol を用いてDNS configuration informationの通信を行えるようにするもの。どうやら名前解決そのものの通信は範囲外？
議事録を見る感じでは否定的な意見が多めのよう。
What’s next for MASQUE
MASQUE自体について。現在どうデプロイされているかどうかなどなど。輻輳制御が入れ子になっている場合とかについての研究が必要など。
なんにせよ、ちょっとまだわかないことが多すぎました。
webtrans
Agenda
https://datatracker.ietf.org/meeting/120/session/webtrans
chair slide(というかwg全体で1つの資料)のみ。
W3C WebTransport Update
IETF 119からのupdateとして、retransmissions and send orderについてのnote、相対URLのサポート、データグラムを優先するがストリームをブロックしないようにする(実装依存)挙動についてなどがあった。ブラウザのサポート状況は変わらずなのかな？Safari(WebKit)にはいくつかissueが作成されている？
あとはいくつか追加された統計情報についてそれが実用的なのか、不足しているものはないか、実装が可能かなどの議論もあった。
WebTransport over HTTP/2
Key ExportersについてHTTP/3の場合と同様でいいのかの確認。"This is the first time key exporters would be available to Javascript in a browser.“ らしく、TLSを解釈する(復号できる)proxyが間に存在する場合に動作しないかも、という指摘があった。
Mozilla (Firefox)は6ヶ月以内にWebTransport over HTTP/2を実装するらしい。canisueによればWebTransportはFirefoxにおいて既に実装済みというステータスだけど、これはover HTTP/3ってことなのでしょう。Bugzillaは 1874097 - WebTransport over HTTP/2 かな。
相互運用性のテストが終わるまでdraftの更新はされないということになった模様。
WebTransport over HTTP/3
"Data Recvd” について、懸念事項があるのでpull reqにコメントするという発言。"subprotocol"という単語の使用について"protocol" を使用するよう変更することが決まった(W3C updateの議題のときに)。
HTTP authenticationの使用可否については、禁止する理由がないということで使用できるという方向でまとまった。
DRAIN_WEBTRANSPORT_SESSIONについてはめっちゃ議論が長びいてて、さらに数回議論が行われそう。
David thanks the academy, his family, and all the friends he made along the way. In lieu of flowers he requests PRs and comments.
ccwg
Agenda
https://datatracker.ietf.org/meeting/120/session/ccwg
Increase of the Congestion Window when the Sender Is Rate-Limited
送信者のデータ送信がrate limitedな場合における輻輳ウィンドウの増加について……？この挙動について、十分な送信が行われていない場合には輻輳ウィンドウの増加に制限をかけるようにする提案。"Who thinks we should not do work on this topic" が0 votesなので、肯定的な反応。
BBR Congestion Control
GoogleとMetaの人によってInternet-Draftが作成されている！BBRv3がRFCになるかも。BBRはGoogle内部のtrafficとGoogleが提供するサービスで使用されている(YouTubeとかgoogle.comとか)。BBRv1とBBRv3でのA/Bテストが行われている。公平性についての発言がいくつかあったけど、ここで課題になっている公平性ってどういうことなんだろうか。
BBR Improvements for Real-Time connections
これもできたてホヤホヤのdraft。BBRのstartupには2*RTT必要で、かつWi-Fi環境においては容易に停止及び悪化するなどなどなどの問題点がある。Real-Time接続、特にメディアに関することについてはmoq側との連携が必要では、という話も。
HPCC++: Enhanced High Precision Congestion Control
データセンターにおける通信は超低レイテンシと高い帯域幅がある。そのような環境に向けた新しい輻輳制御アルゴリズムとして提案されているのがHPCC++。そういう環境では正確なテレメトリが得やすいというのがあるのかな。ccwgでやるべきかどうか……という感じ？
SEARCH – a New Slow Start Algorithm for TCP and QUIC
これもホヤホヤdraft。"Slow start Exit At Right CHokepoint" でSEARCH。特に無線ネットワークにおいて既存のTCP Cubic with HyStartはスロースタートからの脱出が早すぎる？ためにリンク使用率(とは何？)を低下させる。とはいえHystartがない場合はスロースタートの期間が長すぎ不要なパケロスが生まれる。ack済の配送に基づく輻輳制御をTCP senderが行うようにするSEARCHは既にLinux kernel v5.16 moduleとして実装されて評価済み。
主な著者の所属であるviasatはアメリカの通信事業者で、衛星通信事業が主っぽい。wgの反応としては前向きな感じ。
Prague Congestion Control
It is mainly based on experience with the reference Linux implementation of TCP Prague and the Apple implementation over QUIC, but it includes experience from other implementations where available.
とのことだけど、"TCP Prague"というのはなんだろう？https://github.com/L4STeam/linux がそれっぽいのだけど。地名のプラハに由来してるのかな？よくわからなかった。実装としてはTCP版がいくつかのLinux kernel versionsで(前述含む)、UDPのものが https://github.com/L4STeam/udp_prague にある。
実装から得られた知見を反映したdraftが欲しいというコメントで終わっている？
Rechartering
5033bisの取り組みが終わったことについての情報の反映、輻輳制御がいかに重要であるかの文言の追加、などなどなどについて。
minutesを読んでも着地点はよくわからないけど、まあ https://datatracker.ietf.org/wg/ccwg/about/ の文章の更新がされるのでしょう。
CC Response While Application-Limited
時間切れとのことで触れられなかった。
moq
Agenda
https://datatracker.ietf.org/meeting/120/session/moq
IETF 120が終わってからこの記事を書いてるあいだにもうinterimがひとつ、さらに予定としてもうひとつあって議論が活発だ……
あと、minutesに書かれている順にまとめているけど、2回目 → 1回目で書かれている？
WARP Streaming Format
どのようなUpdatesがあったのか。CMAFに加えてLoCのパッケージもサポートされるようになった、タイムライントラックの提案、Chatの内容をどのようなフォーマットで送信するかなど。
着目している人数が少ないことに注意したほうがよいとのコメントがある。
Metrics/Logging
ホヤホヤ。Media over QUICのログやmetricをどうするかというdraft。QUICの上に乗るということでqlogかと思いきやデータモデルにはOpenTelemetryを使うらしい。好意的な反応。
“Peeps” an Extended MoQT Object Model
“An Extended MoQT Object Model” として提案されているもの。PDFの5ページがつまりこれは何なのか、の説明なのかな。議論の様子を見るに好意的に受け入れられてる感じはする。
Track Switching in Media Over QUIC Transport
挙げられている問題を解決するのにとるべき手段がこれなのか、という議論になったように読める。
MoQ Transport Issues
“github.com/moq-wg/moq-transport” 上のissueについて。ここで議論されてることについては実装を知らないと理解できないことばかりに思えるのでパスで……
Livestreaming this meeting over MoQ
この会議の様子をMoQで配信してたらしい。配信するサイトはMetaの人の管理するドメイン上にあった。short.gy っていうURL短縮サービスがあるんだね。
The MoQ Journey
これはなんというか、これまでのMoQの軌跡まとめみたいなものかな。現状がどうなってるかわかっていいですね。
MoQ Transport-05 updates+priorities
MoQ Transportのdraftにおける03、04、05での更新まとめと、新しい優先度とグループの送信順番、次に送信するものは何かということについて。主に現状共有っぽい？minutesを見る限りではここではそんなに議論されてない印象。
Common Catalog Format
individual draftからwg draftになったのが6月のこと。新規のIANA registry “MoQ Streaming Format Type” が定義されたり、fieldやroot objectの追加、renameなどなど。
trackのformatについて、MIMEではなく文字列なのは何故か、IANA registryは必要か？などの議論があった。trackのtype属性について、任意でいいのでは？という話も出ていたが、相互運用性のためには取りうる値はどこかに定義があるべきだろう(それはcatalogではなくWARPかも？)という話があった。relative track prioritizationについては必須であるべきだという意見。Streaming formatに入る値はどのようなものであるべきかについては単なる文字列の識別子(バージョンは含まない)が格納されることで合意。
う〜ん、何ひとつピンとこないですね。やっぱり実装しないとわからない領域なのかも。実装する気はないけど……
MoQ Secure Objects
MoQ Transportにおけるend-to-end encryption。minutesからは、なぜSFrameにしないのか、いやSFrameは嫌だ(というより同じことのやりなおしになるのが嫌？)、などの意見が見られたけど、結論としてこの提案自体がどうなったのかについてははっきりしない印象。
https://sora-e2ee.shiguredo.jp/sframe
SFrameっていうのがあるんですね。
The Many Faces of SUBSCRIBE
SUBSCRIBE を実装して得られた知見についての共有。これはライブストリーミングを実装した人にはピンとくるんだろうか……ギブアップです。
まとめ
なんもわからん。
これは再掲になるんですが、sylph01さんとIETFなど標準化活動について話した内容をPodcastとして公開しました。ぜひ聞いてください。そして文字起こしを買ってください。
2024年07月31日
IETF 120 Vancouver
5回目のIETF Meeting参加シリーズ、リモート参加の4回目です。期間中のバンクーバーはUTC-7(PDT)なので、日本からだと1時から13時の範囲となり、リアルタイムの参加はあきらめていました。
参加したセッション
「参加したセッション」とはいっても前述のようにリアルタイムでmeetechoに入るのは厳しく、基本的に資料と議事録を見て書いています。httpbis、httpapi、masque、webtrans、ccwg、moqについてもまとめようと思ったんですが、一旦7月中に出すことを考えると余裕がなく、力尽きました。追って書くかもしれません。
2024-08-21 追記
書きました。
IETF 120 Vancouverにリモート参加しました その2
Transport Layer Security (tls)
Agenda
https://datatracker.ietf.org/meeting/120/session/tls
ML-KEM Post-Quantum Key Agreement for TLS 1.3
draft自体は今年3月から更新はされていない。Named Groupに mlkem768(0x0768) と mlkem1024(0x1024) を足すという提案。MTI(Mandatory To Implement、必須実装)にはしないという。MLKEM512 も欲しいという声や、文書を分割したほうがいいのでは？という案が出てきているが、前回と比較して提案自体はおおむね前向きな印象？
The Transport Layer Security (TLS) Protocol Version 1.3
エラッタの修正が入っている。X25519をMTIとするかどうかで投票が行われたようで、結果としては今は行わないということに。
Hybrid key exchange in TLS 1.3
X25519Kyber768Draft00はChromeとCloudflareでもう使用できるようになっていて、20%のnegotiationsにおいてこれが使われるようになっている(マジで！？)。
https://pq.cloudflareresearch.com/ にアクセスすると X25519Kyber768Draft00 が使われているかどうかわかります。
Chrome 127.0.6533.73
Firefox 128.0.3
TLS Formal Analysis Triage
“Formal Analysis Triage Panel” ではなく “Formal Analysis Triage Team” ということになった？略して “FATT"。学術論文の査読のように匿名で行なわれていることに対する議論が行なわれていたように見える(賛否両論)。というかこの議論を簡潔にまとめられる気がしないので気になる人は議事録を参照してください。かなり長い。
A well-known URI for publishing ECHConfigList values
ドラフト自体の説明は ECH の config を well-known URI で配布するドラフトのメモ - araya’s reservoir に詳しい。i18nの問題があるらしいけど、それは国際化ドメイン名のことなんだろうか？"more generic?” とされているけど、ECHだけではなくkey_shareなどTLSで必要なパラメータの公開のためにも使うことはできないのか？みたいな議論がされたみたい。dnsop wgと連携する案も。
TLS 1.2 is in Feature Freeze
TLS 1.2にはpost-quantumのサポートは入らないだろう(しかしminutesを読むと逆の意味にも取れるような……TLS 1.2にpq関連のものを追加することを咎めないようなニュアンスの記録がある？)。
SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH)
ドラフト自体の説明は TLS Encrypted Client Hello用のSSLKEYLOGFILE拡張の提案仕様 - ASnoKaze blog に詳しい(いつもありがとうございます)。SSLKEYLOGFILEにおいてEncrypted Client Helloが行われた場合における鍵も記載するようにしたいというのは、それはそう。
もう既にいくつか実装がある(！)。SSHKEYLOGがTLSのセキュリティを崩壊させるという意見、いやいやデバッグ用なのでそういうものではない、など意見の対立はあったものの採用する方向でいくことになっている。
Extended Key Update for Transport Layer Security (TLS) 1.3
長生きなTLS connectionにおいての鍵更新をなんとかしたいという話。TLS 1.2での再ネゴシエーションが脆弱であるということでTLS 1.3では削除されている仕組み。(ラムダノートさんの「プロフェッショナルTLS＆PKI改題第2版」では「8.1 安全でない再ネゴシエーション」として記載があります)
これが、通信インフラやIoT機器などのコネクションが長生きする場面において通信内容をよりセキュアにするために有用であるという提案。仕組みではpost-quantumでも使われるKEMを使う？RFC 9180を参照するとのこと。
以上が前回書いたこと。SSH3のケースを考えると有用だ、という意見。前向きなように見える。
Towards SSH3: How HTTP/3 improves secure shells | APNIC Blog
TLS Trust Expressions
ドラフトの内容については 信頼しているCAをネゴシエーションする TLS Trust Anchor Negotiation のメモ - ASnoKaze blog を参照してください。
Trust Anchor IDsとTrust Expressionsのどちらを採用するか、という投票の結果はTrust Anchor IDsが優勢。その場合のShort CA Nameってどう決めるんだろう。IANAに置くのかな。
QUIC (quic)
Agenda
https://datatracker.ietf.org/meeting/120/session/quic
Multipath QUIC
Chair slideにおいて3GPP(モバイル通信規格の標準化プロジェクト)との連携があることが述べられている。3GPP側からはATSSSの内容においてこのMultipath QUICのdraftを参照しているよ、という連絡があった……と書いてあるけど、その3GPPのドキュメントがどこにあるのか、探しかたが全然わからない……Zennでの解説は発見しました。
Multipath QUICそのものについては、Frame名が変更されたり、エラーコードをどうするか、pathがタイムアウトしたときにどうするか、実装間の相互運用性の状況はどうか、などもりだくさん。
qlog
時刻表現を相対的なものか絶対時刻のどちらを採用するかという議論が行なわれたようだけど、議事録を見る感じではどっちに決着したかがわからない。
IETF 120が終わったタイミングで https://github.com/quicwg/qlog/pull/433 が出ている。この提案だとどのような時刻表現を採用しているかをlog先頭で宣言する形式か。……複雑ではないかなあ。
Accurate ECN
ACCURATE_ACK_ECN frameの導入によって輻輳制御アルゴリズムに対しより詳細な情報を提供できるようにしようというもの。累積のECNカウントではなく、個別にどのpacketがCongestion Experiencedとなったかを知れるようにしたい。そもそもコンセプトに反対だったり、ack frequencyのほうがよいのではないかという意見があった。QUICの拡張としてやってみようという結論になったように読める。
HTTP/3 Prioritization in the wild
特定のdraftというよりは現実世界における調査のまとめのよう。 Extensible Prioritization Schemeというのはこれかな。
各ブラウザおよびサーバー実装のサポート状況、fetchpriorityの効果についてまとめられている。うまくいってない感じ……？
QUIC tokens
RFC 9000における
When a server receives an Initial packet with an address validation token, it MUST attempt to validate the token, unless it has already completed address validation. If the token is invalid, then the server SHOULD proceed as if the client did not have a validated address, including potentially sending a Retry packet. Tokens provided with NEW_TOKEN frames and Retry packets can be distinguished by servers (see Section 8.1.1), and the latter can be validated more strictly.
https://datatracker.ietf.org/doc/html/rfc9000#section-8.1.3-10
という記述にあいまいさがあり、NEW_TOKEN か Retry で送信されるtokenは区別できるべきで、serverが不正なRetryトークン以外は正常なclient initialを受信した場合は直ちに INVALID_TOKENエラーで接続を閉じなければいけない。このとき、NEW_TOKEN と Retry トークンの区別が曖昧な場合は誤った処理が引き起こされる……？
“Extensible tokens” がこの問題を解決できるかもしれない、という意見があるけど、"Extensible tokens"とは……？
まとめ
むずかしいですね。こんなにあやふやなまとめになってしまって誰に需要があるのか……1人でこんなに追うものではないのかもしれません。
あと、sylph01さんとIETFなど標準化活動について話した内容をPodcastとして公開しました。ぜひ聞いてください。そして文字起こしを買ってください。
