先月に引き続き、HTTPSを話せるようにするための作業を続けてはいるのですが、過程でのRecordの持ち方を変えるためのリファクタにてこずったり、別件で書かないといけないコードを書いていたり、Kaigi on Rails 2025のproposalレビューが始まったりと、またしても作業する時間が取れていません。7月からはKaigi on Rails 2025の準備が本格化するというのになんてこった。
それはそれとして、Claude Codeに対して「とにかく続きの実装とテストを書いて」と頼んでぐるぐる回しています。成果物の正しさの確認とか、本当にQUICを話せているのかなどの検証は一切しておらずひたすらコードを生成させ続けているのですが、これを書いてる時点で 224 files changed, 31476 insertions(+), 481 deletions(-)
という成果になっています。
こうなってくると人間がコードを書く時代がいつまで続くのか不安になってきますね。QUICの実装はもちろん完成させたいのですが、どのような実装なのかは自分が全部把握できている状態でいたいので、補完や数行程度のコード生成にはGitHub CopilotなどのAIを活用していますが、Claude CodeやGemini CLIに実装を任せるつもりは今のところありません。
でもそれって、結局自分が書いたコードがどんなYARV命令列になるのか、ひいては最終的にどんな機械語に行き着くのかを理解していないのを受け入れているのに、Claude Codeの生成したコードを受け入れるのを嫌がるのは、そこにどういう気持ちの差があるのかという話になってくる気がしていて、そういう意味では自分はRubyを書いていたいんだろうなと思います。こういう、人間が理解したいだとか、自分でコードを書きたいだとかの欲望がボトルネックになる世界……
osyoyuという人にそそのかされ(?)、Alert protocolの実装より先にクライアントとしてHTTPSリクエストを送信、サーバーからのレスポンスを復号ということをできるようにしようとしています。何も異常が発生しなければAlert protocolを話す必要はないですし。
ただまたしても全然コードを書けていません。5月はちょっとプライベートの予定をいっぱい入れてしまいました。
4月は全然手が動いていません。言い訳をすると、3月はIETF 122 Bangkokのまとめを書いていましたし、その後はRubyKaigi 2025の準備及び参加、Kaigi on Rails 2025の準備もじんわり始まっているので、それらでかかりっきりになってしまいました。
5月はAlert protocolの実装ができたらいいな、なんて思ってはいますが……
3日目に起きた瞬間から強い頭痛、倦怠感、発熱している感じ(計ってはいない1)があり、その時点で安静にしたほうがいいと判断し、よろよろとコンビニでポカリ、inゼリーを調達したあとはホテルでずっと寝ていました。その朝の時点で他のNOCメンバーが同様に体調不良でダウンしていましたし、昼以降も体調を崩すNOCメンバーが出てきてバタバタと倒れていってやばい……という様相でした。
発症時点ではとにかく頭痛!頭痛!!頭痛!!!という症状だったので、これは何か風邪、インフルエンザでもうつされたか、嗅覚はあるしコロナの線は薄いのか?なとど色々考えていました。翌日以降からは頭痛に加えてずっとお腹を下しっぱなし状態で、まあしんどかったです。ブログ公開の時点でもまだ全快してないです。おなかがゆるゆる。
Day 0 で #rubykaigiNOC メンバーでご飯行ったところ当たったのではという説が濃厚で、来年からは全員で同じところに行くのを禁止します
— そらは (@sora_h) April 19, 2025
多分これなんじゃないかなと思います。Day 0の設営の後、みんなで晩ご飯を食べに入った焼き鳥居酒屋がラストオーダー寸前で、そのタイミングでドカドカ注文した結果として焼きの甘かった鶏肉を食べてしまったんじゃないか、という予想をしています。いや、あったんですよ。「これちゃんと火通ってる?」ってやつが。ただ明かりが暗かったのと、まあいうて焼き鳥屋が客に出してて火が通っとらんことないやろ……という慢心で判断をミスりましたね。実際、そのメニューを食べなかったおしょうゆは最後までピンピンしていました。そういう目線で症状を見ると、カンピロバクター、サルモネラ、そんな感じの症状でまあ妥当なんじゃない?となりますね。来年は全員で同じところに行くのをやめる、リスクを感じたらちゃんと引く、を胸に刻んで臨みます。パイロットか?
では本題に戻ります。
いやもう、全部わかります。
(文脈 : プロポーザルの余白を読み解くRubyKaigi 2025 - connpass)
わかっているんです。
以下5冊購入させていただきました。
特に「入門 OpenTelemetry」と「パーフェクトJava」は自分の今の業務でまさに必要な本だったので、ここで買えてよかったです。
#rubykaigi #rubykaigiNOC
— てるふの (@terfno_mai) April 18, 2025
クソクイズ2025の午前問題出てます。 pic.twitter.com/Eg1FpLchz0
そもそも8の字巻きコンテストや、NOCクソクイズをやっているのはなぜか?という話をします。NOCチームの存在や、NOCチームの仕事については知られているのでしょうか。その認知(NOCチームというものがあり、ネットワーク関連のなにかをやっている、程度)を得るためにやっています。あとは楽しいから。
8の字巻きコンテストについては「8の字巻き」という技能を要求されるので参加のハードルはあるかもしれませんが、NOCクソクイズはもっと気軽に参加してほしいですね。我々が頭をひねって「そんなん考えてもわかるわけないだろ」な問題をお出ししているので、頭空っぽにしてぼんやり思いついた答えを書いてもらうとか、大喜利のつもりで臨むくらいでちょうどいいです。参加賞も景品もありませんし。
例えばこの画像のQ3「この付箋(み)の意味は?」『まいた』『み』『ま』なんですが、答えは……
です。わかるか!!ちなみにQ4が結構すきです。どこか(多分Discord)で他の問題の回答も発表されるでしょう。
例のごとくRubyKaigi後もしばらく滞在し、近辺を観光しました。もちろん病み上がりっていうか完治してないままに歩き回っていました。おしょうゆ、運転ありがとう……
しまなみ街道・尾道・佐田岬灯台・宇和島・四万十川・四国カルストを高速履修しました
— osyoyu (@osyoyu) April 21, 2025
今治が抜けてた!
— osyoyu (@osyoyu) April 21, 2025
中村見てる pic.twitter.com/9ijJoZYr6R
— osyoyu (@osyoyu) April 21, 2025
Oura ringによれば体表温は+3.0℃ ↩
バンコクはUTC+7なのでTZ自体は参加しやすいんですが、日中は仕事があるので結局ほとんどリアルタイムでは聞けなかったという……
それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。内容の誤りなどについては責任を取りません。
今回のinteropではメディアに関するデモも追加、実施されたよう。
このmoq-wasmの中の方のscrapも参考になるのでは。
Media over QuicTransport(MOQT)動向まとめ
という訳で僕からは軽めに。全然わからないので……あと事前にagendaに記載されていた “Reducing time to first byte” は触れられてないような気がする。見落としているのかな。
IETF 122以降、07から10での変更について。いっぱいある!07から08が一番変更が多くて、08から09ではそうでもなく、09から10は文書の位置が移動しただけ。エッジケースでの挙動が明確になったのがほとんど?
ビデオ会議で、2人目が入ってきた場合に最初に部屋にいた人の挨拶がちゃんと2人目に届くようにしたい。そういう問題を解決するための議論なんだけど、そもそも今のmoqではそれが保証できないのか?どういう理屈で保証できないんだろう。スライドにはプロトコルを理解している人にはわかりそうな図が貼られている。
スライドにはQuestionがあるけど、録画を見た感じでは一気に"Track Alias Alternate Proposal"まで飛ばして議論が始まっていた。pull reqがまた作られる?
QLOGでmoqのイベントも記録できるようにするもの。今回は紹介のみで時間切れかな?
全員が08まで実装が完了していて、10まで実装しているのが4人。08から10までの差は大きくないのでよい結果という結果。
aboptionへの賛否に関する投票が行なわれ、賛成多数でadoptionされる流れに。
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で揉んでいこうフェーズかな。
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にあったけど時間が足りなくて取り上げられなかった。
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
こういうツールがあれば輻輳制御アルゴリズムの変更を提案する人が自分達で全てのテストをしなくてよくなるので重要だ、という意見があった。
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の必要性などについて。
前回から、投票によってwg draftになったもの。"rate-limited"が指すものについて明確にすべきだ、など文書の明確化についてが今後の課題。
SEARCHを実際に運用してみた結果の報告かな?HyStart、HyStart++、BBRとの比較のグラフがある。帯域がどう増加していくか、メモリ使用量はどうか、それらのテストはどのように行ったか。"Looking for volunteers to try it out!“ という点については前回と変わらず。
Location headerに関する議論の決着がついたらWGLCに進むっぽい。
00からの更新は、non-capsule modeが削除された。終了時の扱いについてどうするかの合意ができてないので、そこが議論のポイントだったぽい。まだまだGitHub issueでの議論が続くのかな。
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に進むぽい。
06においては記述の大幅な変更(editorial overhaul)、expiresがmax-ageになったりとか。media-typeでapplication/partial-upload
を使う際、今はPATCHだけどPUTもしくはPOSTのほうがよいか?という議論があったがPATCHで進みそう?WGLCも近そう。
HTTPにおいて追加の証明書を使用した認証を行う方法について。耐量子暗号の証明書(という表現は正しいのか?)の場合はサイズが大きいために複数のフレームに分割せざるをえないという問題について、新しいストリームタイプを使う場合についての調査を行うことで落ち着いたよう。実装ボランティア募集中!
スライドなし。サポートしているサイトは https://chromestatus.com/metrics/feature/timeline/popularity/4425 で確認できる。これをクライアント側として実装しているブラウザはChromeのみ。WGLCに進みそうな感じがする……
Comic Sansだなあ。シグナリングについて3つ(もしくはそれ以上)の状態を持つべきかどうか、クライアント側がincrementalいけるぜ状態をどうサーバーに伝えるか、サーバーに中間者がincrementalできるかを伝える方法はどうか、などが議論。シンプルであることがより良いという意見があり、tri-stateにはならなそう?
例えばgzippedされたresponseを返すとき、そのdigest値を Repr-Digest
で返し、gzipする前の内容のdigest値を Unencoded-Digest
で返すようにするもの。range requestとかHTTP Signatureでユースケースがあるということだけど、いまいちピンと来てない……名前に関してどうするかという議論がある。
スライドなし。rfc6265bisが更新されることはないっぽい、が、rfc6265bisをさらに修正するための取り組みはあって、そっちには入る可能性がある?Shopifyの人だ!
スライドなし。rfc6265bisではない版のやつ。このwgでやるのが相応しいかどうかの質問で終わったか?
Client Hintsは最初のリクエストではサーバーが何に対応しているか不明なので最適化できず、例えば何もかもを送信するとそれはそれでプライバシーの問題がある、と。そのためにCritical-CHヘッダやACCEPT_CH frameを提案している。多くの人がmic queueに並んだようで、質疑が多い。やりとりするデータが増えることによるパフォーマンスの低下が懸念されていたり。
ECHのキャッチアップが足りなかった、というのが僕の感想です。
Last Callになって色々なレビューがあった。ECHに関してはDNSDIRからちょっとした質問が返ってきている。svcb-echのほうは同じくDNSDIRから "I think it’s ready to go.” が返ってきている。
これ(IETF 122)が終わったらLast Callするって!!
IETFでやることか?というところに関して一悶着あったけど、結局は取り組みが継続されそう。一悶着あったというのは、これはメッセージ内容を復号できるのでよくない、いやいやデバッグ用のツールなので通信内容の漏洩にはならない、という議論。
Formal Analysis Triage Team (FATT)による8773bis(External Pre-Shared Key)のレポート。果たしてPSKは量子耐性があるのか。ということで8773bisを複数の研究者にレビューしてもらった。研究者は暗号計算と記号解析の分野を研究対象としている人達で。全員がTLSに関する公開された成果がある。研究者は公開されているが、レビューコメントのどれが誰によるものかは公開されない。レビュワーに直接連絡はせず、リエゾンに対して質問やコメントを送ってほしいというお願い。
解析結果そのものは「8773bisは既存のTLSに対する脆弱性を導入するものではなく、追加の解析を行う必要もないだろう」「量子耐性については懸念事項がある」というもの。なので量子耐性に関する主張を削るか、または維持するのであればさらなる解析が必要ということに?
議論はそもそもTLS wgとして量子耐性についてどういう立場でいくべきか、という内容になっていそう。結果いくつかの投票が行われ、一番賛成票を集めたのは「TLS wgがセキュリティに関する主張を改訂するべき」という設問。
クライアント側からmTLSできますよをサーバーに伝えられるようにして、認証されたbotからのアクセスを許可したいというユースケース。侃々諤々?DANEで役立つかもしれないという話が出た。
*No discussion*
PAKE(Password Authenticated Key Exchange Extension for TLS 1.3) に関する2つのdraft。ユーザーがパスワードやPINを入力することでの認証、組み込み機器のセットアップ、ペアリング時のユースケースが提示されている。AirPlayやMiracastのときのPIN入力の画像がスライドに添付されている。
TLS wgとしてやることには賛成多数、やるならhandshakeでやるべきで、post-handshakeではないという結論になった。
ロシアでECH(Encrypted ClientHello)がブロックされてる(されてた?)のか……ECHを使うクライアントが、ECHを使っていることがわかってしまうのでプライバシー的に問題だったり、ECHを解釈できないサーバーはどう振る舞うのが正しいのか、などの問題がある。提案されているのは、ECH configとouter SNI(これなんだっけ?)が一致しない場合にサーバーは中断してはならない、outer SNIは事実上の非推奨にするなど。
ECHが普通になれば目立たなくなるのでそうなっていくべきとか、確かにこれは懸念すべき事項で、ECHは遅らせたくないがこれにも取り組むべきだ、という意見があった。これはちょっと気にしておかないといけなそうだ。
IETFでは初めて見る雰囲気のスライドだ。これECHのことがわかってないとわからないな……
議論自体の結論は、ECHが完了したらやろうという感じか。
これもECHのことがわかっていないと何もわからない 😇
既存のECHのワークを中断させるものではないとのこと。
Remote Attestationということで、rats wgと関連のあること?スライドの内容も、minutesに書いてあることもよくわからない……
updateがあったので確認してね、くらい?
OpenAPIのmedia typeが登録中?open issuesが2つ。次のIETF meetingまでにWGLCしたい。
様々なフィードバックが得られた。https://github.com/darrelmiller/ratelimiting が C# での実装。フィードバック次第では次のIETFまでにWGLCになる?
MSの jsonschema の拡張提案見た。
— mizchi (@mizchi) March 20, 2025
$defsで再利用する型を厳格化するの、理想はそうだけど運用で上手くいくとは思えない。$offers でallOfやif/then/else を拡張仕様で分離するのは、逆に実装の乱立を招く気がする$import は外部参照解決を複雑化する
総じて反対https://t.co/szxUmN3yBJ
これC#の言語仕様が念頭にあるように見えるな。C#にうまくマッピングする水準に見える
— mizchi (@mizchi) March 20, 2025
今の時代これやるんだったらせめて WASM の Canonical ABI とか Component Model も念頭においてほしい気がする
— mizchi (@mizchi) March 20, 2025
提案しているClemensさんはMicrosoftでFabric Eventstreamなどのメッセージングサービスに関するリードアーキテクトの人らしい。https://cloudevents.io/ にも関わっているのだそう。mizchiさんの言ってる「C#にうまくマッピングする水準に見える」についても、口頭でTypeScriptやJavaScript、C#、Javaへのマッピングができるように設計していると言っている、多分。
強い賛成や反対があったというよりは「とりあえずGitHub repositoryじゃなくてdraftにしてもってきてほしい」っていう結論になった感じかな?
セキュリティ上の懸念事項(上記issue)があるのでSECDIRのレビューを受けたいという意見があった。
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/ で見れるようになっている。
11から13までの変更点は、PATH_CIDS_BLOCKED
frameの追加、複数パスでのPTOにおけるガイダンス、0-RTTにおけるMP frameのエラーコードの修正、その他さまざまな明確化。draft13に対する相互運用性の確認についてもほぼ成功。
PATH_CIDS_BLOCKED
frameって本当に必要?という議論に関しては、これはデバッグのために便利で、既に実装が存在するのでそのまま残すということになったのかな。次の版でWGLCになるかも。
Multipath QUICはアリババもう本番投入している?ホントに?
wg draftになってますね。議事録では “Extension Negotiation” に関する質疑だけ記載されている。草案から “negotiation” という言葉を削除したと。
「遅延を正確に計測することで帯域幅の計測がより正確になる、などのモチベーション」って118のまとめのときに書いてた。他にもAckの頻度を減らすことに関しても重要。ACK frameにいくつかのtimestampに関するfieldを追加したACK_RECEIVE_TIMESTAMPS
frameを使う。そもそも複数のoptional fieldを持てるようACK frameを拡張可能にするか。新しいframeを定義するか、常にtimestampを送信するようにするかという議論がある。
とりあえずdraft自体をquic wgとしてやっていくことは賛成多数だった。
QUICのセッション中に鍵交換は1回行われる。これを draft-ietf-tls-extended-key-update
をベースとして、CRYPTO streamでTLS 1.3のメッセージを送り新規の鍵交換をやる。long-lived sessionにおいて重要だと。具体的にはtelco signaling、IoT、MASQUE/VPNとかだと。
wgとしてこれに取り組むことに関しては賛成多数で可決。
遅いネットワーク上でMacのscreen shareが重いという問題があった。ネットワークのバッファが溢れているんじゃ?という疑いがあり、実際は送信側のバッファにあったと。送信待ちのデータがめちゃくちゃ増えちゃっており、そのため TCP_NOTSENT_LOWAT
が導入されてバッファの量が制限されるようになった。IETF 121のside meetingで、これはバイト数ではなくミリ秒単位の制御であるべきだという話があった。で、QUICはどうする、と。なんかメーリングリストもできてる。
各位この問題にどう対処してる?的な問い掛けのセッションってことだったのかな。IETF 123で何かしらの進捗がありそう。
QUIC on Streams(QoS)名前が不評すぎてウケる🤣 ネタに走った名前をつけたことについては反省してます…
— Kazuho Oku (@kazuho) March 17, 2025
QoS、言われるまで気づかなかったな……
“This will require a recharter” ということで、recharterが行われるかもしれない。
“Taking IP To Other Planets” の略で、惑星間通信のようなRTTがなっっっがい環境における通信では、既存のプロトコルをそのまま展開するのが難しくなるので、そのための拡張などについて議論するworking group。
唯一リアルタイムで聞けたセッション(祝日だった)。tiptopのミーティングは今回が初だったので、記念すべき1回目(?)に参加できたのはよかったです。
そもそもtiptopで想定しているユースケースとはどんなものかについてのdraft(だと思う)。月や火星のような領域がテーマで、低軌道、中軌道、静止衛星くらいまでの地球と近い距離における通信においてはスコープ外。
通信のユースケースとしては、宇宙船などへのコマンド送信、テレメトリデータの送受信、リアルタイムメディア、一時的に通信できない場合の遅延、緊急メッセージ(救助要請とか)、科学的データ、メッセージングとか。
セキュリティやパケロスの問題についての質疑が行われていた。
non-goalとして挙げられているのは、Webサーフィン、sshなどのterminal access、Facetime(などのビデオ通話?)、何かしらのインタラクティブ性が要求されるものとか。
IPv4やIPv6には変更は不要だろう。deep spaceにおいては、パケットを転送する先が存在しない場合があるので、転送可能になるまで長期間保持しておく必要があるだろうというのは確かに。UDPはそのまま使えるが、QUICはRTTが数百ミリ秒であるのが通常なので、デフォルトの構成だと宇宙には持っていけない。これに関してはシミュレーション環境において適切なパラメータのもとではQUICスタックが機能することが確認されている。TCPに関しては未調査。HTTPは、Cache-ControlやExpiresなど時間がかかわってくるheaderを使うのは適していない。などなどなど。
で、そのQUICをdeep spaceにもっていく場合の話。RTTが7日間にも及ぶというのはすさまじい。長いRTTのために、initial_rtt
、max_idol_timeout
などのパラメータを調整したプロファイルの話が出ている。実験環境というのはこれ https://github.com/aochagavia/quinn-workbench かな。
スライドの副題が “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なのでこれから色々決まっていくんでしょう。
2月に亡くなられたBernard Aboba氏への追悼があった。
W3C WebTransport Updateはほぼ完了、最終的には9月にW3C勧告として公開される予定。変更点はリダイレクトをネットワークエラーとして扱うようになったり、stats.atSendCapacity
が追加されたりと色々。
WebTransport上にHTTP/3を実装する……?反応としてはこれは独自のWGでやるべきだとか、webtrans wgのcharterでは対象としてないとか、結構攻めた提案という印象。
う~~んminutesが淡白!
https://datatracker.ietf.org/doc/draft-ietf-wish-whip がAUTH48になってるという議事録が残ってるけど、今見ると https://datatracker.ietf.org/doc/rfc9725/ もうRFC 9725になってましたね。
このwgは閉じられるのか?に関しては、whepがまだあるということでもうちょっと残る?
リクエスト、レスポンスのヘッダに connect-udp-bind
を使うことで、proxyのportをbindする。前回からの更新はeditorialなもののみ。実装はGoogle QUICHEがある、他の実装も探していて、実装しようと思っている人はいる。充分な相互運用性が確認できたらWGLCになりそう。
Googleが実装に対して積極的だけど時間がない、次のIETFでconnect-udpと合わせてinterop testをやろうという提案があった。でも残ってるissueをcloseできたら、そのテストの前にWGLCにする予定?
121からの変更点は配信できないEthernet frameに関しては、endpointはdropしなければならなくなったことと、輻輳制御によるパフォーマンスの懸念事項が追加された。相互運用のための実装募集中。WGLCしたいけど、その前にIEEEからレビューを受けるべきという意見。
これも相互運用性の確認のための実装を募集中か~。
スライドの写真、良い……状況は謎だけど。MASQUEを使うとはどういうことなのか?について明らかにするための文書。Informationalだ。実際、このdraftはMLS architectureのdraftからリンクが貼られている(RFC 9750になる?)。
これが文書としてまとまってるのはいいことだけど、pearg(Privacy Enhancements and Assessments Research Group)の仕事かもしれないという意見。これに時間を割いて議論すべきか?という投票は賛成多数で可決された。
IETF 127は現時点で2026年11月14日からの開催が予定されています。
しかし、現在の米国の状況から、本当にサンフランシスコで開催するのかどうか、そしてサンフランシスコで開催された場合に現地参加できるのかどうかという懸念が高まっています。
これについては今回のPlenaryでも話題に挙がっており、1:57:28以降がそれについての議論です(多分)。ここで発言しているトランスジェンダーの方は、ドイツ政府から「あなたのパスポートで米国に入国しようとすれば、パスポートの詐称とみなされるので逮捕されるだろう」というアドバイスを受けたと述べています。
マジかよ……という感じですね。そしてIETF 127をサンフランシスコから別の場所で開催することを検討しているのか?という質問に対しての返答は「3/5時点では開催地の移動はしないことになっている。ただし再度議論は行われる」というものでした。財政的にも厳しいというのは、Kaigi on Railsの運営として大人数が集まる会議の場所を抑えることの難しさを知っているので十分理解できますが、しかし入国するだけで逮捕される可能性があるっていうのはちょっとなあ……
そしてこんなページができていました。
ページを作成したのは、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を記載していますが、これまでの経緯なんかを自分でも参照するのが面倒になってきたので自分向けでもいいからどこかにまとめておきたくなってきました。
「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_AES_128_GCM_SHA256
のみ)legacy_compression_method
や legacy_session_id
legacy_record_version
引き続きやっていきたいです。
趣味でQUICの実装を、そしてその前段階としてTLS 1.3の実装をしている1者です。TLS 1.3のclient側からのfull handshakeをRubyで不完全ではありますが実装しました。上の画像で ====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が便利」にて。
まずserver側の実装もして、自作実装どうしでfull handshakeを完遂できるように、そして現時点では完璧なメッセージのやりとりがされる前提でのコードを書いているので、各やりとりでMUSTとされている検証を行い、適切なAlertを送信できるようにしないといけません。
というわけで、これから毎月くらいのペースでQUIC実装進捗日記を書けたらな、と考えています。いつまで続けられるかはわかりませんし、あまりにも進捗がなければskipする月もあるとは思います。インスパイヤ元は山本さんの「TLS 1.3 開発日記」です。期待せずお待ちください。
QUICの実装にあたり、完全なTLS 1.3の実装は必要ない(はず)と認識していますが、内包しているプロトコルは理解しておきたいというわがままです。 ↩
趣味でQUICの実装を、そしてその前段階としてTLS 1.3の実装をしている者です。今月中にfull handshakeまで実装しようと思っていたんですが、間に合いませんでした。なのでこの記事は小ネタです。
さて本題の「OpenSSLが便利」とは今更一体何を言ってるだという感じですが、実際便利です。備忘録がてら(僕の)使い方を書いておきます。OpenSSLのバージョンは3.3.1です。
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を(不完全ではあるものの)実装した、という報告ができればいいですね……
なんとこれを書き始めてから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
仕事で触れたものは覚えている範囲で書いています
昨年からのDiffとして、Python、Kubernetes、Cを削除しました。コンテナオーケストレーションはECSしか触ってない1年だったような気がします。使用しているエディタの順は、とうとうVS Codeが1位となりました。
エディタなんですが、プライベートでは主にWindows機(たまにmacbook)を使っており、コードは家の中にあるLinux機に対してSSHして書く、というスタイルでここ数年はやっていってます。そんなスタイルだと、VS CodeのRemote SSHが本当に便利なんですよね。IntelliJ系もJetBrains Gatewayを使えば同じようなことはできるんですが、手軽さと(感覚ですが)ハマることが少ないのでもっぱらVS Codeでやってます。
新しく触れてる技術があまりなく、例年とそんなに代わり映えしないところに若干の不安を覚えなくはないです。そういうものと言われてしまえばそれまでですが。
なんかすっかりまとめ記事を書くのが定番になったような気がしますが、始めてまだ2年目だというのがびっくりですね。
TLSについては同人誌を書くのにいっぱいっぱいだったので実装は全然進んでおりません。あーあー。しかも同人誌は公開すると言いながらそれも全然進められていませんし。この記事を書いてる数日前からようやく実装を再開したという体たらくです。
Kaigi on Rails 2024ではアプリ側のコードは大したことはやってないですが、インフラをHerokuからAWS ECSに載せかえてTerraform管理にしたり、サイネージ(実装が雑!)をつくったりしました。
あとはまあ、お仕事は大抵Railsなので、そんな感じです。
いい加減……実装を……はい……
やるぞ!!!!
……何を?(Kaigi on Rails 2025をお楽しみに)
今年は何度か「海外カンファレンス行かないの?」と言われたので、2025年はひとつくらい参加するのを目標にしてもいいかな?と考えてはいます。行くとしたらやっぱりRails Worldでしょうけど、被ってないとはいえKaigi on Rails 2025が近いのでどうなることやら。