2025年06月27日
6月も手が動いていない(！)
先月に引き続き、HTTPSを話せるようにするための作業を続けてはいるのですが、過程でのRecordの持ち方を変えるためのリファクタにてこずったり、別件で書かないといけないコードを書いていたり、Kaigi on Rails 2025のproposalレビューが始まったりと、またしても作業する時間が取れていません。7月からはKaigi on Rails 2025の準備が本格化するというのになんてこった。
Claude Codeに書かせている
それはそれとして、Claude Codeに対して「とにかく続きの実装とテストを書いて」と頼んでぐるぐる回しています。成果物の正しさの確認とか、本当にQUICを話せているのかなどの検証は一切しておらずひたすらコードを生成させ続けているのですが、これを書いてる時点で 224 files changed, 31476 insertions(+), 481 deletions(-) という成果になっています。
こうなってくると人間がコードを書く時代がいつまで続くのか不安になってきますね。QUICの実装はもちろん完成させたいのですが、どのような実装なのかは自分が全部把握できている状態でいたいので、補完や数行程度のコード生成にはGitHub CopilotなどのAIを活用していますが、Claude CodeやGemini CLIに実装を任せるつもりは今のところありません。
でもそれって、結局自分が書いたコードがどんなYARV命令列になるのか、ひいては最終的にどんな機械語に行き着くのかを理解していないのを受け入れているのに、Claude Codeの生成したコードを受け入れるのを嫌がるのは、そこにどういう気持ちの差があるのかという話になってくる気がしていて、そういう意味では自分はRubyを書いていたいんだろうなと思います。こういう、人間が理解したいだとか、自分でコードを書きたいだとかの欲望がボトルネックになる世界……
2025年04月25日
はじめに、体調のこと
何があった
3日目に起きた瞬間から強い頭痛、倦怠感、発熱している感じ(計ってはいない1
発症時点ではとにかく頭痛！頭痛！！頭痛！！！という症状だったので、これは何か風邪、インフルエンザでもうつされたか、嗅覚はあるしコロナの線は薄いのか？なとど色々考えていました。翌日以降からは頭痛に加えてずっとお腹を下しっぱなし状態で、まあしんどかったです。ブログ公開の時点でもまだ全快してないです。おなかがゆるゆる。
何故
多分これなんじゃないかなと思います。Day 0の設営の後、みんなで晩ご飯を食べに入った焼き鳥居酒屋がラストオーダー寸前で、そのタイミングでドカドカ注文した結果として焼きの甘かった鶏肉を食べてしまったんじゃないか、という予想をしています。いや、あったんですよ。「これちゃんと火通ってる？」ってやつが。ただ明かりが暗かったのと、まあいうて焼き鳥屋が客に出してて火が通っとらんことないやろ……という慢心で判断をミスりましたね。実際、そのメニューを食べなかったおしょうゆは最後までピンピンしていました。そういう目線で症状を見ると、カンピロバクター、サルモネラ、そんな感じの症状でまあ妥当なんじゃない？となりますね。来年は全員で同じところに行くのをやめる、リスクを感じたらちゃんと引く、を胸に刻んで臨みます。パイロットか？
では本題に戻ります。
登壇したかったニャンね2
いやもう、全部わかります。
(文脈 : プロポーザルの余白を読み解くRubyKaigi 2025 - connpass )
わかっているんです。
トーク
本屋
以下5冊購入させていただきました。
特に「入門 OpenTelemetry」と「パーフェクトJava」は自分の今の業務でまさに必要な本だったので、ここで買えてよかったです。
#RubyKaigiNOC
そもそも8の字巻きコンテストや、NOCクソクイズをやっているのはなぜか？という話をします。NOCチームの存在や、NOCチームの仕事については知られているのでしょうか。その認知(NOCチームというものがあり、ネットワーク関連のなにかをやっている、程度)を得るためにやっています。あとは楽しいから。
8の字巻きコンテストについては「8の字巻き」という技能を要求されるので参加のハードルはあるかもしれませんが、NOCクソクイズはもっと気軽に参加してほしいですね。我々が頭をひねって「そんなん考えてもわかるわけないだろ」な問題をお出ししているので、頭空っぽにしてぼんやり思いついた答えを書いてもらうとか、大喜利のつもりで臨むくらいでちょうどいいです。参加賞も景品もありませんし。
例えばこの画像のQ3「この付箋(み)の意味は？」『まいた』『み』『ま』なんですが、答えは……
『まいた』: 8の字巻きしてある
『ま』: 上記「まいた」の略
『み』: 「ま」と書こうとして間違えた ← (これを答える)
です。わかるか！！ちなみにQ4が結構すきです。どこか(多分Discord)で他の問題の回答も発表されるでしょう。
レジャー
例のごとくRubyKaigi後もしばらく滞在し、近辺を観光しました。もちろん病み上がりっていうか完治してないままに歩き回っていました。おしょうゆ、運転ありがとう……
Post by @unasuke@mstdn.unasuke.com
View on Mastodon
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年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が近いのでどうなることやら。
