2025年06月05日
大型自動二輪免許を取りました
何故
バイクってかっこいいから……
2025年06月05日
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が近いのでどうなることやら。
はい。今回はTZ的にはいわゆる仕事が終わった後に開始、というセッションが多く日本からのリモート参加も比較的しやすい回ではありましたが、Kaigi on Rails 2024のアフターイベントとか何やらとかでリアルタイム参加はひとつもできませんでした……
それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。
minutesがいつものHedgeDocじゃなくて https://httpwg.org/wg-materials/ietf121/minutes.html になっているのはなにゆえ……？
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が割り当てられるかもしれない？
120からの主要なupdateとして、Content-Location ヘッダと Location ヘッダの用途についてとそれに設定するURIのガイダンス、Accept-QueryヘッダのIANAへの登録が挙げられている。議事録にはAccept-Queryの値に対してStructued Field Valuesは使わないでくれ、くらいしか記載がない。
スライドがない。とはいえIn WG Last Callだし、もう特に議論すべきこともない段階？
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が多めで前向きな感じがする。
“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を送信することを可能にするか？という議題がある。前進しそう。
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は含まれるのか、とか。
結論としてはもうすこし議論しようということっぽい。
Delete-Cookie ヘッダーで明示的にCookieを削除できるようにする？
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ がちゃんとRFCになってから取り掛かるのでいいのでは？という意見があった。
YANG（ヤン、英: Yet Another Next Generation）は、データモデル言語の一種である。NETCONF や RESTCONF などのネットワーク管理用プロトコルによりアクセスされるネットワーク機器の設定や状態、遠隔手続き呼出し (RPC)、通知をモデル化するために開発された。 https://ja.wikipedia.org/wiki/YANG
netconf wgのdraftについてhttpbis wgからのフィードバックはあるか、というやつかな。肯定的ではあるものの、もっと議論が必要という感じ。
MASQUE for TCPってスライドには書いてるし、そういうものを実現するためのもの？
HTTPの拡張CONNECTメソッド について復習する - ASnoKaze blog で connect-upd を使うという解説があるけど、こっちは TCPの上に載せるのでconnect-tcp を新しく定義して使うとある。
Capsuleを使うべきでは？という意見がいくつか。賛否両論で、さらに議論しようという結論。
もともと “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 というヘッダーで、URLのparamsに入っているものがレスポンスに影響するかどうかを知らせることができるようになる。なのでparamsのバリエーションによるキャッシュのうんぬんを制御できるってことだろうか。既にChromeにはサポートが入っているっぽい？call for adoptionされそう。
上記は前回の自分のblogより。
スライドで「CG Draft」にsuspendedとなっているのは、WICGでの策定？はやめて、httpbis wgでの作業に一本化したということ？なのか？
いわゆるGeoIPの話。間に中間者を挟むなどで自分のIP addrは知られたくないが、地理情報は伝えたい(？)ケースがある。そのときに Sec-CH-IP-Geo で地理情報をサーバーに送信できるようにする提案。目的としてはIP addrによる地理情報の推測をやめていきたい、というものだとか。問題意識はわかるような……とりあえず継続して議論しようというステータス。
この章を書いている途中で 第2回 Media over QUIC とか勉強会 - moq-wasm 開発秘話!!【Media over QUIC とか勉強会】 | 高田馬場 Live Cafe mono に参加し、nttcom/moq-wasmを実装している方々とお話しすることができました。なので色々なワケワカラナイだった部分がだいぶわかるようになりました。やっぱ実装してるとより理解が進むし、実装しなければわからないこともあるということで。
IETF 120からinterim meetingsが12も実施されている。やば。そしてこの記事を書いてる間にもどんどんinterimが予定されていって、今ではこうなっている。
https://quic.video/blog/transfork/ が気になってるけど、議題にはないのかな？まあないか……
一番実装が進んでいるものでも 6 (unsubscribe) までで、7 (goaway) を実装できているものはない。そもそもinteropの内容が120から変わっていなかった、という話も(前述のスライドで)ありましたね。
IETF 120以降でMoQ Transportに入った変更まとめ。超interimがあったので、こういうのがあるのが本当に助かる……そしてまあ、いっぱいありますね。
複数のgroupにobjectが配置されている場合においてRTTを削減できるってことか？beneftとしてスライド内で説明されているのが以下。例えば解像度の切り替えなんかで嬉しいというように読める。議事録によると、スライドにあるproposal #2が賛成多数ということでその方向で進むらしい。
スライド読んで！
priorityについての記述のあいまいさがあるみたいで、そのための議論のよう。複数のgroup間でのpriorityの順序がどうなるか、ということっぽい。これもproposalが2つ挙げられており、決を取ったところproposal 2が賛成多数となった。proposal 2はsubgroup内でuniqueなpriority値をつける方式。見た感じgroupにもまたがっていそうだけど……？
スライド読んで！！
moq wgのプロセス及びワークフローについて。chairがコンセンサスを確認できていない、virtual interimで物事が進んでいて参加できない人がおいていかれる、運営が難しいという問題が挙げられている。いくつかの解決策が挙げられていて、議事録を見た感じではそれで合意した……？
なんか色々ある……まず、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として最低限どこまでサポートするべきか、みたいなところが今後のワークで明確になる？
スライド読んで！！！
解像度を変えるなどしたい場合に、新しいgroupを受信しても今ある解像度から新しい解像度とのgroupの間のobject(？)をもらわないといけないとき、SUBSCRIBE+UNSUBSCRIBEか、それにFETCHもまざってくるかというケースの複雑さを解決するために導入する仕組みがSWITCH。具体的にどうするかについてはこれからっぽい。
スライド読んで！！！！
Delivery TimeoutとMax Cache Durationが相対的でありベストエフォートである。もしパケロスや順序の入れ替わりがある場合にskewedとなる。エンコードに時間がかかるケースにおいてはcaches upできない？？optionalな"timestamp"を導入することで解決するということらしいが。わかりません！
latencyの計測のためにmoqt上で時刻のmetadataを交換できるようにするっぽい。地理情報も含められるようになっている。しかし事情によりskipとなった。
recharterするっぽい？その兼ね合いでテストスイートがあると嬉しい、古くならないよう長期的にメンテされているべきだ、みたいな話がされていた。これ、Hackathonと関係していそうだけど。ns-3っていうやつが便利なツールっぽい。
なんか日本の大学の名前が見える……
なんかあったらしい。"Design a suite of test cases based on 5033bis, the proposed new BCP on Specifying New Congestion Control Algorithms" は超ステキだと思うが。成果は……どこにまとまってるんだろう？？？
変更点としては、wg draftになっているとか、元文書がXMLからMarkdownになっているとか、明確化したとかとか。軽微なアルゴリズムの変更をするpull reqが2つopenになっていて、TCPでないtransport(主にQUICのことを指してる)に対する一般化についてのissueがopenになっている。
現実世界でのdeployに協力してくれるボランティアを募集している段階？ccwgのワークとして取り組むことに賛成の意見が多いので、引き続きなにかしら行われそう。
送信者のデータ送信がrate limitedな場合における輻輳ウィンドウの増加について……？この挙動について、十分な送信が行われていない場合には輻輳ウィンドウの増加に制限をかけるようにする提案。"Who thinks we should not do work on this topic" が0 votesなので、肯定的な反応。
が、前回。これも投票の結果、ccwgのワークとして取り組むことに前向き。
スライドの最後がオシャレ。ccwgのワークとして取り組むことの賛成は反対より多かったけど、no opinionを含めてあまり差がない感じ。どうなるんだろう？
他のものについては時間切れ。
こんなwgありましたっけ……？って思ったけどpast meetingsは110からあって完全に節穴でしたね。
WebRTC Ingest Signaling over HTTPSなのでWHIP/WHEPのwg。
WebRTC のシグナリング規格 WHIP と WHEP について が概要をつかむのにはわかりやすいかも。
agendaはこれだけ。そしてin WG Last Call状態。行われた議論自体はGitHubで未解決のissueについてとWHEPについて。WHEPはURLをどうするかについてどうしようか状態なのと、失敗(何に？)した場合の振る舞いについて定義しないといけない、ということについての議論があった。minutesを読むと議論があったことはわかるけど結論は書かれていなくて、合意に至らなかったのかな。
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になるかどうかについては、もう一回改訂を重ねるということになった。そもそもやろうとしてることが多くて大変とも。
なんだこの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に向けて解決しないといけない、というところで終了。
P2Pな状況におけるQUICにおいてpublic addressを検出、シグナリングするための拡張。そもそもquic wgとして取り組むべきかどうかについての投票が行われ、賛成多数。
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の図)
フィードバック求む！状態。
httpなpathにrequestをした場合、httpsへと301 redirectするというのはありふれている。このとき最初のnon-secureなrequestにapi keyなどのcredentialが含まれているとunsecureだよね、という話。このdraftはBest Current Practiceなやつ。serverおよびclientに最初からsecureな通信での開始を行うための指針を提供するもの。HSTSとかHTTPS DNS recordとか。
なぜスライドにこんなに映画ネタを……？ https://httpsig.org/ を今さら見て気付いたけど、Ruby gemとして https://github.com/nomadium/linzer というのができているのか。これはRFC準拠っぽい。
RFC 9530のDigest Fieldでdigestが不正だった場合に、RFC 9457の仕組みを用いて結果を返すためのschemaを定義するものかな？
oracle attackに注意というコメントがあった。
OpenAPIやJSON Schemaをresponseとして返せるようにするもの。レビューしてlast callの準備ができたか確認するということになった。
そういえばRate limitの仕組みがRailsに入ったよな……
patition keyが入った？のかな、これは便利という意見があった。
いつ見てもなんかSEGAを彷彿とさせる。
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には一致するバイト列が含まれており、プロキシの両側のフローを対応することができる、と……結論としてはこのような攻撃手法がある、という対応のみに留まりそう。
前回(っていうのは120のこと？)からの変更は特になく、WGLCになるまでに相互運用性があると嬉しいので、実装に意欲的な人を募集中、という段階。hackathonで1つ実装した、という話があった。Googleによるもの。それってこれのことなのかな？ https://github.com/google/quiche/commit/29f785f59dfb33f4fff4c87852983c2cb7808ad0
hachathonでericsson clientとgoogle serverとのinteropが行われたとのこと。もっと他の実装も募集中。輻輳制御に関して未解決の問題が残っている。これについてどうすべきかはまだまだ議論が必要という感じになっている。
dnsop wgに持っていって早期レビューを受ける流れ？
会場めっちゃ広くない？？？？？
あとIETF 121が終わってからML-DSAがめっちゃもりあがってるんだが……
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 Registyに入った変更について。"A stunning presentation.“
issueについて議論する回。AD reviewでついたDNSの問題については、合意に至らずADからの勧告があれば従うと。他にもいくつかあるopen issueについての議論が行われた。今repoを見てる感じでは、それらに対応した変更がcommitされていそう。
FATTの現状について。議論は公開されるべきだ、という意見が多い。(動画だと結構長い時間話してたけどmisnutesがアッサリめ)
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を作るよ、という話になったぽい。
certificateの圧縮。pass 2は複雑(これ2パス圧縮のことでいいのかな？)なので辞書なしのBrotilを使おうという提案がある、と。よりシンプルになるが圧縮率は落ちる。それはそれとしてZstdとBrotilのどっちでいくかはまだ議論中かな？
ExtendedKeyUpdateRequestを受信したときにalert & terminateしていたのがExtendedKeyUpdateResponseを返すように定義されたり、ExtendedなKey Updateが実行されたときにSSLKEYLOGFILEにどう記録するか、などの更新。未解決issueはもうない！
最新のWiresharkではもうサポートされている！！
アー