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として公開しました。ぜひ聞いてください。そして文字起こしを買ってください。
2024年06月23日
高専DJ部とは
https://kosendj-bu.in
なりたち
そもそも高専DJ部は高専カンファレンスという高専生を中心としたコミュニテからのスピンオフになります。もともとは音楽が好きな人達が「高専DJ部」という名前でFacebookにグループをつくっていて、それが2013年の4月5日とのことです
(中略)
というわけで初イベントは2014年5月31日でした。Facebookにグループをつくってから1年と少しでイベントをやるまでになりました。
高専DJ部について - 良いあそなすちゃん
これが高専DJ部のなりたちです。このときから、rooqさんを部長、asonasさんを顧問として、およそ2ヶ月おきに早稲田の茶箱で高専DJ部は開催されてきました。
僕が高専DJ部を知ったのは高専生の頃、たしかTwitterで流れてきのがきっかけで、東京で就職できたら行ってみたい、できればDJとして出てみたいなあと思ったものでした。
当時はUstreamで配信していたんですね。
そして僕は東京の会社に就職し、高専DJ部に現地参加できるようになりました。僕の初DJは高専DJ部第8回のことでした。
https://github.com/kosendj/kosendj-bu.in/blob/master/archive/08.yml
引き継ぎ
そして高専DJ部第8回からDJを始め、よほどのことがなければ毎回DJとして立候補を続けていました。
そんな折、asonasさんが多忙になるということでゆるやかに運営業の引き継ぎをはじめ、第19回以降は僕がオーガナイザーとしての取りまとめを行うようななりました。
その後、開催頻度が3ヶ月毎になったり、配信がTwitchになったりと細かな変更はありましたが、とうとう2024年6月1日の回で第40回かつ10周年を迎えることができました。
第40回では、僕がクラブミュージックを知る切っ掛けとなったKONAMIのBEMANIシリーズから、10年前の稼動シリーズであるbeatmania IIDX 22 PENDUALから中心に曲をチョイスしました。音ゲー君すぎましたね。
高専カンファレンス界隈に向けて
高専DJ部は、前述のように高専カンファレンスからスピンオフとして始まったクラブイベントです。そして10周年を迎えるわけですが、ひとつ課題があります。それは最近新入部員がめっきり減っていることです。そもそも認知すらされていないかもしれません。
ここ最近、コロナ禍で途絶えてた高専カンファレンスの開催がどんどん勢いを取り戻している様子を観測しています。
https://kosenconf.jp
そこで再度現役生や、卒業したばかりの元高専生に高専DJ部の存在を(再度)知ってもらおうと、僕が行ける範囲で参加して高専DJ部についての話ができればいいなと最近は考えています。
首都圏に在住していない方々には、無理に来てほしいとは思っていませんが、とりあえず知っていただけたら、よければ開催しているときにはTwitchでの配信を観ていただければと思います。もし興味があれば、Discordサーバーもあるので覗きに来てください 。x.com/kosendj や x.com/yu_suke1994 に話しかけてもらうのでも大丈夫です。
そんなわけで、これからの高専DJ部もよろしくお願いします。
https://kosendj-bu.in
2024年05月30日
はじめに
昨年は英語で書いたんですが、今年は発表できなかったので日本語で書きます。
登壇したかったニャンね
いや〜〜〜〜〜〜〜〜〜〜〜〜……はい。
特にしおいさん、いまいずみさんと僕はRubyKaigi Takeout 2021での初登壇以来、RubyKaigi 2023まで連続してacceptされていたので、勝手に同期みたいな仲間意識を感じていたのですが、今年は僕がnot acceptedとなり、ぐぅぅぅ……という感じです。まあnot acceptedとなることに対しての納得はあるので、精進が必要、といったところですね。
トーク
まともに聞けているのがあまりない……以下箇条書きで感想を書いていきます。
The depths of profiling Ruby (osyoyu)
言いつけどおり最前待機した
“Software profiling is a never-complete art”
Exploring Reline: Enhancing Command Line Usability (ima1zumi)
いまいずみさんに教えてもらうまで .inputrc の存在を知らなかった
ちょっとしたスクリプトで gets.chomp じゃなく Reline.readline するの、いいな……
これを書いているときに思ったのが、passwordなどのsensitiveな入力をRelineで受け取るのはどうやるんだろう
An adventure of Happy Eyeballs (coe401_)
Happy Eyeballsは2020年度のGrantでの松下さんによる取り組み があってから色々あったのか、なかなか本体に取り込まれなかったけど、しおいさんの努力によって本体に入ってめでたい
ところでHappy Eyeballsにはv3の提案があってですね……
Leveraging Falcon and Rails for Real-Time Interactivity (ioquatix)
Samuelファンボーイかつ勝手にライバル視している身としては見るしかないセッション
発表内容は面白かったし、Kaigi on Rails向けといわれるとそれも一理ありますね
SamuelのGitHubで彼の作っているものを追っていくと色々とすごい
そのことについて、STORES CAFE at RubyKaigi 2024でJeremyと話しました(なんなんだあれは、我々にはできない、的な)(みんなもdigってみよう)
Getting along with YAML comments with Psych (qnighy)
インターネットではお見掛けしてるけど直接話したことはなかったくないさん
YAMLのコメントを吐きたい要望って世にはあまりない？みたいな質問をしたり
思ったけど、YAMLってlibyamlなどで出力するんじゃなくて、テンプレートエンジンを使って出力する(helmとか)ケースのほうが多いのかもしれない
An mruby for WebAssembly (udzura)
以下の投稿を参照
これはRubyKaigi 2024の前週に開催されたTSKaigi 2024でmizchiさんと話していてワクワクしていた
というのも、初学者が選ぶ言語としてRubyが選択肢に上がらないのは何故か、という問題意識が(個人的に)あり、例えばNext.jsだったりedge functionとしてのJavaScriptは無料で動かす環境がそれなりに揃っているのに対し、Railsなどサーバーとして動くインスタンスが必要になる場合はあまり無料枠でいろいろいじれる環境がなくなってきているので、その辺で手を出しづらくなっていたりしないか、みたいな仮定をしていました
そして、ではEdgeでRubyが動く未来が来るとどうなるのか、そもそもEdgeでRubyが動くためには/選択肢のひとつになるには何が不足しているのか？みたいな議論をTSKaigiの場でmizchiさんとしていたのでした
速度さえなんとかなればmrubyでWASMでedge computing with Ruby、アリなんだよな……
Adding Security to Microcontroller Ruby (sylph01)
これ！！！！これですよ。
レビューしていただいた本 もお渡しできて何より
TLS(HTTPS)文脈というよりはCBOR/COSE/CoAP、これは確かにそう
Ruby Committers and the World
「Rubyをキメると気持ちいい」みたいなのは、型による補完がバチバチに効くことでも得られる体験だったりしない？
特に初学者にとってはリファレンスと反復横飛びしなくてもよくなるという点でも型の情報があるとよいと思う
コード内に書かせない、せめてコメントによる注釈が黙認レベル、というところに異議はない
自分はPromise, async/awaitが出てきたあたりでJavaScriptを書く機会が増えたのであまりインデントが延々と深くなるcallbackを書いた経験はないけど、それでもasync/awaitが出てきたのは嬉しいポイントだとは考えている
非同期処理の記法としてのasync/awaitがあるべき姿か、と言われるとわからない
ビルドシステム、マルチプラットフォーム対応でつらくないものって、そもそも存在するのだろうか
defer/ensureについて、隣に座っていたosyoyuがsyntax errorになる記法を発見したのでこれは “来る” か？となった
しかし文法の変更はPrism/Lramaのためにしばらく入らない宣言がされており……
コミュニケーション
やはり普段会えない人と会えるというのはとても貴重な機会でした。STORES CAFEでJeremyを独り占めしてOpenBSDのことを教えてもらったり、いまいずみさんと英語トークの(自分なりの)準備のしかたについて話したり、RubyKaraokeで転岩を2回リクエストされたり、RubyMusicMixinでありたそと限界になったり……
#RubyKaigiNOC
昨年までは得に何も考えずにスケジュールを決めた結果、NOC完全撤収の前に帰ってしまうという(自分的)失態をしたので、今年はちゃんと最後の集荷のスケジュールに合わせて帰ることにしました。ので自分史上最も長くRubyKaigiの会場付近にいたことになります。これは来年も継続していきたいことのひとつです。
NOCの仕事としては、ネットワーク構築、発注したケーブルの巻き直し、当日のケーブル敷設、AP設置、会期中の運用、クソクイズ出題、そして撤収などなどなどがあります。このうち、僕が関われるケーブル巻き直し、敷設、設置、撤収については、特に今年はKMCからの若者が多数参加してくれたおかげで、会場作業については例年の比ではない速度で完了させることができました。本当に助かりました。
ところで皆さんはDay 0の準備中や、Day 4の撤収作業をDiscordで配信していたことにお気付きでしたか？
Day 4は何人か聞きにきてくれたのを観測しています。来年どうなるかはわかりませんが、おもしろコンテンツとして聞きにきてくれたらいいかなと思います。
レジャー
完全撤収日まで滞在すると数日何も作業予定のない日が発生します。このタイミングで沖縄を満喫しました。
#rubyistsonwaves
おしょうゆという人がいます。僕は彼に「沖縄行くんだったら船舶免許取ったほうがいいよ」と背中を押され、取りました。
そして土曜日、海へ……
海に出たあとは戻ってバーベキューをしたりして、これは完全に “陽” だな……と改めて思います。
この日は海から帰った後、なはーとで少しNOCの撤収作業があったのでそりゃ夜にはこうなりますわな、という写真です。
ドライブ
それでもまだ数日の空きがあり、その日はKMCのメンバーで沖縄ドライブをしました。民泊でバーベキュー、美ら海水族館、植物園、辺戸岬、ダム見学、タコライス、24時間営業のmelonbooks……沖縄でやるレジャーっぽいことをそこそこやれて良かったです。
やっていくぞ
RubyKaigiが終わったら、Kaigi on Railsがやってくるわけです。Kaigi on Railsがんばりモードに切り替えて、やっていきます。
また、ふと思い付いた取り組みがあり、関係者には企みを話して「やろう」ということになったので、やっていきます。こういう話が顔を合わせてやれるのもRubyKaigiのいいところですね。
2024年05月25日
3行で
本について
TLS 1.3のRFCを読んでいく本：キリンセル
詳しくは以前の記事、「C103の2日目(12/31)にTLS 1.3についての同人誌を頒布します」 を参照していただきたいのですが、要はRFC 8446の日本語訳にちょっとした解説などが付いた本となっています。
物理在庫について
以前の記事でも書いたように、物理の在庫を売り切るまでは物理本の通販はしません。また、よっぽどのことがない限り物理本を再度印刷することもしません。物理は売り切ったらそこまでのつもりです。
また、後日公開予定の電子版については、本当に本の内容のみ公開予定で、つまりナナメさんのイラストについては当日会場、または電子版を購入していただいた方のみの限定コンテンツとなります。(おまけポストカードはそれなりの数を用意したので、会場で売り切れとなった場合に余っていればお渡しします)
電子版について
本来、この本はPDFやEPUBなどの形式による頒布をするつもりはありませんでした。ですが技術書典ということで、電子版を用意しました。こちらの電子版にはナナメさんによる表紙絵とイラストが含まれています。(電子を用意するつもりがなかったのは、まずは物理の在庫をなくしてしまいたいので……本がぶ厚いんですよ！8mmあります！)
この電子版についても、可能であれば技術書典16終了後に頒布を停止する予定です。
取り置き制度(C103同様)
pixivFANBOXおよびGitHub Sponsorsで支援していただいている方に対しては、連絡をいただければ取り置きをさせていただきます。当日お渡しする際には支援していることの確認となるものを提示していただくかもしれません。準備をお願いします。詳しくは各プラットフォームからの連絡をご参照ください。なお、申し訳ありませんが支援金額を頒布価格から差し引くという対応はしません。まあそんな爆裂に売れていくなんてことはないと思いますが……
さいごに
TLS 1.3のRFCを読んでいく本：キリンセル
手ぶらで帰りたい！！！皆さんよろしくお願いします！！！！！「か 01」でお待ちしています。
2024年04月28日
まさかこんなことになるとは
以前のブログ記事 でも書いたように、バンドを組み、オリジナル曲「タワーマンの孤独」を含む3曲を演奏しました。まさかこんなことになるとは。
経緯
経緯についてはなぜか動画が公開されているので、そちらを見ていただくのでもいいです。なぜあるんだ？
VIDEO
VIDEO
というわけで、あそなすさんという方にめちゃくちゃ「バンドやろうぜ」という勧誘を受けていて、根負けしました。
ただ押し切られて嫌々始めたわけでもなく、昔から家族や友達など周囲に楽器を演奏できる人がおり、興味がなくはなかったことと、「How To Become A Hacker」 に
なにか楽器を上手に演奏したり、歌が歌えるようになること。
とあることから、楽器を演奏できるようになることには憧れがありました。問題は初期費用とか、練習する時間が確保できるのかとか、そもそも練習しても全然弾けるようにならなかったらとかいう不安もありましたが……
というわけで背中を押され、ギターを買いました。
ハネモノ
まず簡単な曲が弾けるようになろうということで、スピッツの「ハネモノ」 を課題曲として課されました。
これがそのままライブで披露する1曲目になりました。ハネモノを家で練習しながら、月に1回くらいのペースでスタジオに集まって練習をしていました。
転がる岩、君に朝が降る
その後、流れで次の曲はASIAN KUNG-FU GENERATIONの「転がる岩、君に朝が降る」 にしようということに決まりました。これは確かスタジオ練習で決まったことなのでテキストのログがありません。
オリジナル曲「タワーマンの孤独」
そして2曲目を決めたのと同じタイミングで、新曲をお願いして作ってもらおうということになりました。というのも、仲間内のDiscordでもともとChatGPTやSuno.aiを使った謎の曲がchiastolite さんの手によって生み出されており、これをちゃんと編曲してもらったらいいんじゃないか、ということになったのです。
編曲は樫野創音さん (@kashino_tsukune) にお願いしました。
快く引き受けてくださり、また素晴らしい曲に編曲していただき本当に感謝しています。この場を借りてお礼させていただきます。
編曲していただいたものをみんなで聞いたとき、本当に良い曲になっていて感動すると同時に、「これ、自分に演奏できるのか……？」と不安にもなりました。これが3月上旬のことです。
その後練習を重ね、なんとか弾けるようになり、ライブ本番を迎えます。
ライブ
楽しかったです！！！！！！！
来ていただいた皆さん本当にありがとうございました。
そもそもライブで初お披露目となる曲でみんながノッてくれるのか、という不安がありましたが、冒頭の「Road to 1st LIVE うなばん！」を作成したjigsaw さんにより歌詞のカラオケ表示があったおかげで、大盛況だった……と聞いています(演奏してるとそこまであまり気にする余裕がない)。本当にありがとうございました。
また、初ライブ&誕生日(誕生日ではありません)祝いということでなっちゃん(@pndcat) にケーキを頂きました。ありがとうございました。美味しかったです。
こうしてみると、バンドメンバーはもちろんそうですが、それ以外にもたくさんの方々が関わってくれていることがわかります。とても大きな感謝の気持ちと、ちょっぴりの「あなたたちのせいですからね」という両方の気持ちがあります。これからもよろしくお願いします。
次回
ukfesはまた開催されるということもあり、2度目のライブに向けてまた演奏できる曲を増やしたりなんだりやっていくつもりです。がんばります。
2024年04月02日
要約
2024年4月27日 17:25 ~ 23:00 ukfes が大岡山劇場にて開催されます(詳しくは以下URL)
「うなばん！」で以下3曲やる予定です
スピッツの「ハネモノ」
ASIAN KUNG-FU GENERATION の「転がる岩、君に朝が降る」
新曲(オリジナル)
来てくれ！！！！！！！！！！！！！！！！！
バンド結成しました
めちゃくちゃ勧誘されたので、ギターを買ってバンドを組むことにしました。メンバーは以下です。
うなすけ(僕) ギター、ボーカル
りょぺこさん ギター
あそなすさん ベース
ukさん ドラム
おしょうゆさん キーボード
バンド名は「うなばん！」です。ホントに？いい名前が思い浮かんだら変わるかもしれません。
「新曲」？
初ライブでオリジナルの新曲があるの正気か？と思うんですが、あるのでしょうがないです。この新曲についてはライブが終わったあとに書こうと思っているふりかえりで色々書くつもりでいます。曲はめちゃくちゃカッコイイので気になってる人はぜひukfesに来てください！！！！！！！！！！！
2024年03月31日
IETF 119 Brisbane
IETF Meeting参加シリーズも4回目、リモート参加シリーズだと3回目になりますね。2024年3月のIETF Meeting 119はオーストラリアのブリスベンで開催されました。TZはUTC+10なので日本からリモート参加しやすかったです。
オーストラリアといえばカンガルーということで、参加者向けメーリングリストでは「カンガルーに遭遇した場合はどうすればいい？Internet Draftの共著者にならないか誘うべき？」などの会話が行われていました。
参加したセッション
前述したとおりブリスベンのTZはUTC+10なので、各種ミーティングがUTC+9の時間で生活している自分にとっては人道的な時間に開催されるのは助かりました。ただ、それはつまり日々の仕事などの日常生活とバッティングするということでもあり、どのみちフルで参加することはできませんでした。
あとやっぱりリスニングは壊滅的でした。本当にわからない。
それでは以下、常体です。
Media Over QUIC (moq)
Agenda
https://datatracker.ietf.org/meeting/119/session/moq
Readout from Hackathon
MoQの6つある(？)実装のうち、5つはversion 3(draft-ietf-moq-transport-03)に対応したとのこと。具体的にどの実装が、みたいな情報が見あたらないけど……
Subscribe and Fetch (draft-ietf-moq-transport)
SUBSCRIBE が送信されるとき、実際には何が送信されるのか、subscriptionの重複が存在する場合にオブジェクトが何度送信されるかが不定、などなどの不明瞭および不正な点がissueとして挙げられていて、それを解消するために FETCH という仕組みを提案するもの。
Fetch is a “StateFul” request, finds out about “non-available objects” in that range.
と述べられている。
そんなわけで今はここで議論が進められているのかな？
Split SUBSCRIBE into SUBSCRIBE and FETCH by ianswett · Pull Request #421 · moq-wg/moq-transport
draft-ietf-moq-transport
で、それとは別にdraft-ietf-moq-transport-03でのupdateの報告。いくつかのメッセージがmerge、追加されたり、曖昧な部分の明確化が行われた。今後の課題としては前述のSubscribeの問題の他に、Transmission、Object Model Details、Handshakeがあるとのこと。
draft-mzanaty-moq-loc-03
CMAFに代わるメディアフォーマットであるLOC(Low Overhead Container)を標準化するもの。WebCodecベースで、CMAFよりもオーバーヘッドが小さい。
03でなんとMLSの仕組みを利用したE2EEへの参照 が追加されたり、Audio/Video共に様々なパラメータや拡張が追加された。
“Separate packaging container format from MOQ Streaming Format?” に関して意見が分かれていたようだ。
draft-wilaw-moq-catalogformat
catalogのupdateにJSON Patchを使うようになったり、トラック名が相対的に、名前空間を継承するようになったりする変更がmergeされている。今openなものとしてIANAにcatalog fieldsを登録したり、trackに共通するfiledsを持てるroot objectを追加したりなどがある。
Call for Adoptionということは近いうちにWG draftになるのかな。
WARP draft Update (draft-law-moq-warpstreamingformat)
https://datatracker.ietf.org/doc/draft-law-moq-warpstreamingformat/
話されてた？議事録にも特に詳細がないので新しいtopicはなかったのかも。
Transport Issues (draft-ietf-moq-transport)
そしてMoQ Transportのissueについての議論。このへんちょっと議題の認識がごっちゃになってるかもしれない。GroupおよびTrackが終了するのはいつか、優先順位はどうするか、みたいな議論がもりあがっていた。次のIETF Meetingまでにinterim meetingをやろうという意見が投票多数。
Lessons from implementation
https://datatracker.ietf.org/meeting/119/materials/slides-119-moq-simulcast-video-delivery-learnings-01
サイマルキャスト、優先度、輻輳制御について。回線状況が不安定な場合の挙動について色々課題が出てきていて、FECについての研究やmoq WG以外のWGと連携することも提案されている？(BBRv3の改善とか)。
Bandwidth measurement in MOQ
https://datatracker.ietf.org/meeting/119/materials/slides-119-moq-bandwidth-measurement-for-quic-00 (pptxです)
様々な映像ソースを使って帯域測定をした結果とのこと。Özyeğin University(なんて読むんだ、トルコのオジェギン大学？)の方からの発表。
帯域幅測定はクライアント側で行うことが可能。共有だけで特に議論とかはなかった……のかな？(録画を見てるけどたぶんない)
MoQ Secure Objects
MoQでE2EEをやるための仕組みの提案。CMAFのほうにはCommon Encryption(cenc)というのがあるんだけど、それの代替というわけではなく、Low overhead containerのほうでcenc的なことを実現するためのもの(そのまま使うことができないので)。
新しい暗号を導入するのではなく既存のHKDFとAEADを使う。MLSやLOCとのeasy integraionを目指している。“Why focus on low bandwidth” に “Lyria is a 3kbps audio codec. Newer ML codecs are use even less bandwidth.”(原文ママ) とあって、Lyra、あったな～～～となった。
Lyra V2 - a better, faster, and more versatile speech codec | Google Open Source Blog
質問でCGM-SSTなるものに言及があったけど、これだろうか。
https://datatracker.ietf.org/doc/draft-mattsson-cfrg-aes-gcm-sst/
そして内容がよく聞きとれなかったけど、議事録には “Maybe use GCM-SST? (Sure)” とあるのでこれを使うということ？
WebTransport (webtrans)
もともとQUICに興味を持ち始めたきっかけがWebTransportだったのに、このWGを追うのを忘れていたな～、と。
Agenda
W3C WebTransport Update
WebTransportに関わる標準化はIETFとW3Cの両方で進められていて、W3CのほうはWeb browser APIとかを担当している(という理解をしている)。
W3CのほうでのWebTransportは、6月にAPIを安定させ、8月には複数の実装が存在している状態を予定しているっぽい？
めちゃくちゃ長い名前のオプションが追加されてる。
現時点でSafariのみが未実装。 https://caniuse.com/mdn-api_webtransport
draft-ietf-webtrans-http2
118から 08が出て、CLOSE_WEBTRANSPORT_SESSIONとDRAIN_WEBTRANSPORT_SESSIONがHTTP/3のほうから追加されたり、いくかのcapsuleがrenameされて短くなった。
draft-ietf-webtrans-http3
https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/
https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/ への参照が追加されたり。Flow controlについてどうするかの議論がさかんだったかな？ただinterimは予定されなかった。
QUIC (quic)
masque wgも追いかけたほうがいいのかなという気持ちもありつつ、もういっぱいいっぱいなので……
Agenda
FECについては発表だけ、Accurate ECNは時間切れになりました。
QLOG (draft-ietf-quic-qlog-h3-events)
Dune: Part Two観てないんですけど、観たほうがいいですかね。
118以降、QPACK関連のイベントが削除されたり、イベント名がちょっと変わったり、Multipathのサポートが入ったりした。今年末にはWGLCしたい、という雰囲気？
もっとMoQ wgと連携していこう(あとでメールしてほしい)、という話が出た。
Multipath QUIC (draft-ietf-quic-multipath)
Path IDをどうするか、interopの結果がどうだったかなど。Path IDについては292で提案されているExplicitなものと現在の06とのPros/Consがそれぞれ挙げられている。MPTCPというのがあるのか。
retire CID on all pathsについては賛否が分かれたのかな？
Ack Frequency (draft-ietf-quic-ack-frequency)
いくつかの文章と変更と明確化、特に対応せずcloseしたものなど、前回からの変更についての報告。
2度目のWGLCを119が終わったあとにしたい。
QUIC security considerations
https://datatracker.ietf.org/meeting/119/materials/slides-119-quic-honeybadger-and-his-friend-the-mongoose-00
QUICに対するリソース枯渇攻撃についての共有。HTTP/2 Rapid Reset Attachに似ている？QUICサーバー側のactive_connection_id_limitを越えてNEW_CONNECTION_IDをはちゃめちゃに送りつけるという攻撃、なのだろうか。
https://seemann.io/posts/2024-03-19-exploiting-quics-connection-id-management/
この記事に詳しく記載されている。
QUIC on Streams (draft-kazuho-quic-quic-on-streams)
新キャラ。TCPとUDPでの二面待ちをしたり、新しい概念が導入されたときにTCPとUDPの両方に対応する必要があったりするので、TCP上でQUICを話せるようにしようというもの。QUIC on Streamsはあくまでもfallbackであって、TCPで発生し、QUICが解決したHOLBの問題はこっちでも頑張って解消しようとはしていない。……で、あってるのかなあ。
スケジュールだと5分という話だったけどまあ5分で終わるはずがなく。どっちかというとQUICを推し進めていくほうがいいのでは？という反対意見のほうが多かった……のか？
BDP frame (draft-kuhn-quic-bdpframe-extension)
BDPは”Bandwidth Delay Product”の略。輻輳制御に関するパラメータを両者間でやりとりして、Careful Resumeを実現するもの。もしかしたらCCWGでやることになるかも？QUIC WGがこれを進めていくかについては賛否が分かれた。
Transport Layer Security (tls)
Agenda
8446bis/8447bis
Chairのところで止まっていて、報告されているエラッタを処理しなければいけない。なんかエラッタを草案のコメントとして使ってる人がいて？全部closeになるかも、という話をしていたかも。
ECH Update (draft-ietf-tls-esni)
Encryptred Client Helloになってからも、Encrypted Server Name Indication時代の名残で draft-ietf-tls-esni なの、混乱しますよね。
これも今月いっぱいはIn WGLCという報告。
Registry Update
https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-tls-registry-updates-00
IANAの人からの報告。rejectされたrequestはなし。Extensionがいくつか増える(スライドにあるのは4つ)。ALPNも作業中のものがCoAPの表記について？
TLS Hybrid Key Exchange (draft-ietf-tls-hybrid-design)
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
大幅には変わっていないが、Hybrid Groupsの数が2つに削減された( X25519Kyber768Draft00 と SecP256r1Kyber768Draft00 )。FIPSの認証と、共有鍵と合体させる(？)方法についてが残っている問題。
“Chrome announced today they are going to release an experimental version.” って言ってて、どれだよ……となっている。
一番「それっぽい」のはDev channel 2023-03-16の 124.0.6356.6のリリース(上の2つめのリンク)で、“Enable PostQuantumKyber by default on desktop” っていうcommitが入ってる。でもこれAndroid……？3つめのリンクはそのcommitに関連付けられているChromiumのissue trackerにおけるチケット。diffの中身も「っぽい」んだよな。Firefoxのほうは “Firefox is shipping in nightly currently.” とのことで。https://bugzilla.mozilla.org/show_bug.cgi?id=1871629 から辿れそうだけど具体的なcommitまではわからなかった。
TLS Obsolete Key Exchange (draft-ietf-tls-deprecate-obsolete-kex)
これ、 In WG Last CallになってるけどExpiredっていうStatusはアリなのか？(chairの作業で止まってる、とスライドにはある)
FFDHEについて、TLS 1.2では Discouragedに、TLS 1.3ではNot recommended(議事録ではOKとしか書いてないけど、でもrecommendedではないでしょう)となることになりそう。
Static DH Client Certificatesについても非推奨とされる流れ？
TLS Formal Analysis
https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-formal-analysis-triage-panel-00
個人的には今回のTLS WGのミーティングで最も盛り上がった議題だと思う。8773bisがlast callするにあたり、いくつかのWGのメンバーから「その変更に対するformal analysis(形式的分析)が行なわれていない」という意見があったらしい。
つまりTriage panelを置き、TLS 1.3の標準に変更が入る際にはtriage panelに連絡し、そこで正式にformal analysisを行うかどうか判断するようにしようという提案っぽい。
“Not just Tamarin” というのは標準化界隈でよく使われる(らしい)セキュリテイプロトコルの検証ツールとのこと。
https://tamarin-prover.com/
で、not justなのでTamarinに限らず様々なツール、手法で検証をしようじゃないか、という。
賛成の声が多い感じ。学生を巻き込みたいという意見もあった。
Super Jumbo Record Limit (draft-mattsson-tls-super-jumbo-record-limit)
SUPER JUMBO
TLSのrecord size limitを RFC 8449にて定められている2^14 バイトから 2^16 バイトまで拡張できるようにするもの。データセンターで有益という意見。性能指標についてどうなるのか、という疑問点が挙げられ、今後識者と協力してやっていく、ということに。
mTLS FLag (draft-jhoyla-req-mtls-flag)
クローラー、Botが「自分は真正なクライアントですよ、ほら証明書がありますよ」をサーバーに知らせるためにmTLS readlyであることを送る仕組み。
実はもうここ https://tls-flags.research.cloudflare.com/ で動いている。CとGoでの実装もあるみたいだけど資料には記載がない。でもGoは多分これ https://github.com/cloudflare/go/pull/151
“I would like to see enthusiasm.” ということは、もっと協力なニーズがないと厳しいのか？
Extended Key Update (draft-tschofenig-tls-extended-key-update)
長生きなTLS connectionにおいての鍵更新をなんとかしたいという話。TLS 1.2での再ネゴシエーションが脆弱であるということでTLS 1.3では削除されている仕組み。(ラムダノートさんの「プロフェッショナルTLS＆PKI改題第2版」 では「8.1 安全でない再ネゴシエーション」として記載があります)
これが、通信インフラやIoT機器などのコネクションが長生きする場面において通信内容をよりセキュアにするために有用であるという提案。仕組みではpost-quantumでも使われるKEMを使う？RFC 9180 を参照するとのこと。
設計が複雑になるのでは？という議論になった感じだろうか。
ML-KEM for TLS 1.3 (draft-connolly-tls-mlkem-key-agreement)
耐量子での鍵確立をやるってことですね。Named Groupに mlkem768(0x0768) と mlkem1024(0x1024) を足す。ていうか、耐量子暗号って7年前には既に提案されていたんですね(早すぎるのでは？というFAQ)。
hybridでやるべきでは？という意見、RFCではなくコードポイントの定義だけでいいという意見、強く支持するという意見、これはひどいアイデアだという意見などなどなどがあり、一体どうなっちゃうの～～？
まとめ
むずかしいですね。mls、httpbis、httpapi、ccwgについてもまとめたかったんですが、ギブです。
2024年02月25日
楽々静的HTTPサーバーことpocke/wwwとは
これらをご覧ください。ちょこちょこpull reqを投げていたらコミット権をもらえたので気付いたときに触っています。
タイトルでは「v3.0.0をリリースしました」と言っていますが、その前段階で v2.0.3 をリリースしているので、ついでにそれにも触れていきます。
v2.0.3
この変更で行なったのは以下の2つです。
Windows版buildの配布を追加
deprecatedとなったioutil.ReadFile の削除
Windows版buildの配布を追加
僕はたまにWindows環境でwwwを使いたいことがあったのですが、リポジトリのreleaseにはLinuxとDarwin(macos)向けのビルド済みバイナリしか存在しませんでした。GoなのでWindows版バイナリを用意するのは簡単ですが、用意されているほうがありがたいですよね。
wwwはリリース作業にGoReleaser を使用しているので、.goreleaser.yaml を用意してWindowsをtargetにしてやるだけで対応完了です。
ちなみにpull requestは1年以上放置していました。よくない。
deprecatedとなったioutil.ReadFile の削除
エディタでmain.goを開いたときに気付いたのですが、内部で使用しているioutil.ReadFileがdeprecaredとなり警告が発生していました。
これは単純に os.ReadFile に置き換えるだけで対応完了です。
v2.1.0
HTTPSへの対応を追加しました。
HTTPS対応
これについては、himanoaさんのこの発言を見たのが対応のきっかけです。
そんなわけで、 --cert と --key に証明書のpathをそれぞれ指定することでhttpsによるリクエストを送ることができるようになりました。このoptionは、両方を指定しないとエラーになるようにしています。
まとめ
CHANGELOG.mdとかあったほうがいいのかな、という気もしてきましたが……そこまででもないかな？とにかく、pocke/www は便利なのでよろしくお願いします。
2024年01月28日
予習
「RubyKaigi 2024に向けて泡盛を予習しておきたい」ということになり、今月頭に沖縄に行ってきました。
写真
以下、様子です。
知見
高速道路に合流がなく料金所を通過すると即本線なのが新鮮
ステーキが本当に美味しい
自販機のラインナップが新鮮
美ら海水族館のリン子どんはもっと知られてほしい
いわゆるスパムおにぎりはツナのほうがいいかも(まだ食べれていない)
泡盛コーヒーは知能が高い飲み物であり、ファミマは知能が高いコンビニ
海が綺麗
国際通りのドラッグストアには酒豪伝説があるので安心
2023年12月24日
3行で
C103 2日目(12/31) 東ヘ17a 「キリンセル」にて「TLS 1.3のRFCを読んでいく本」を¥3,500で頒布します。
内容はTLS 1.3についてのことで、表紙と挿絵をナナメさんにお願いしました。
物理の本のみ頒布します。電子版については後述しますが、現時点では存在しません。
本について
コミックマーケット103 2日目(12/31) 東ヘ17a 「キリンセル」ブースにおいて、「TLS 1.3のRFCを読んでいく本」を頒布します。この本は、Rubyアソシエーション開発助成2022 において、aiortc/aioquic をRubyに移植する際の経験をもとに書くことにしたものです。
aioquicには、TLSの実装が含まれています。そのTLSのPython実装をRubyに移植する際になかなかうまくいかず、RFCや実装とにらめっこをするなどの苦労をしたので、TLSのRFCを日本語で解説してくれる資料がないだろうかと思い、書くことにしました。
もちろん既に日本語訳を公開されていらっしゃる方もおられますが、やはり自分でイチから写経しないといかんなということで本にしてまとめようと思った次第です。
とはいえあまりに文書量が多く、わかりやすくまとめなおすというのは時間的に無理で、ほとんど日本語訳の形になってしました。それでもRFCには記載のない参考資料へのリンクを追加したり、言い回しをやさしくしたり語句の簡単な解説を足したりと、単なる翻訳ではないような本になるようにしたつもりではあります。
この本については、いずれインターネット上で誰でも読めるような形式で公開するつもりです。その際はMITライセンスやCCライセンスなどの、何らかの自由に利用可能なライセンスを適用します。なので、本当に今すぐ読みたい、何らかの理由でお金を払って読みたいという方でない限り、当日お越しいただく必要はないかもしれません。
そうなってしまうと結局RFC 8446を日本語にしただけじゃないか、ということになるので、ナナメさん にお願いして表紙絵とイラスト数点をお願いしました。これは後々公開予定の文書には含まれず、物理本を購入していただいた方限定のお楽しみコンテンツとなる予定です。当日お買いあげいただいた方には、表紙絵のみを印刷したものもおまけとしてお渡しします。
頒布数についてですが、50部を印刷しました。ただし全部を今回のコミケで頒布するつもりはなく、次回の技術書典でも(もしかしたらその前にRubyKaigi 2024でも)頒布したいと考えており、それぞれで半々ずつくらいで頒布することを考えています。また次回の技術書典で在庫が余るまでは通販もしません。単純に在庫を抱えたくない&発送作業をしたくないという怠惰のアレです。
で、現在「¥?,???」となっている頒布価格についてですが、まだ印刷所からの連絡がなく決めきれないでいます(決まったら記事およびお品書きを更新します)。ただ、¥3,000～¥4,000くらいにはなるんじゃないかなと見ています。利益を出そうとは思っていませんが、そもそもページ数が多いので印刷費がかさみそうです。
見本
見本はコミケWebカタログで確認することができます。
キリンセル | Comike Web Catalog
取り置き制度
pixivFANBOXおよびGitHub Sponsorsで支援していただいている方に対しては、連絡をいただければ取り置きをさせていただきます。当日お渡しする際には支援していることの確認となるものを提示していただくかもしれません。準備をお願いします。詳しくは各プラットフォームからの連絡をご参照ください。なお、申し訳ありませんが支援金額を頒布価格から差し引くという対応はしません。まあそんな爆裂に売れていくなんてことはないと思いますが……
最後に、再度コミケWebカタログにおけるキリンセルの詳細ページを貼っておきます。
キリンセル | Comike Web Catalog
追記 2023-12-29
頒布価格を決定しました。1部¥3,500です。お品書きも更新しています。
なお、すっかり言及を忘れていたんですが、同日東パ03bにて頒布される「桐生あんずファンブック」にて、「Rubyistワカモノ組座談会」で僕が話した内容が本になっています。こちらもよろしくお願いします。
|
|
