この度，JPNIC様の国際会議参加支援プログラムにご採択いただき，IETF 117に現地参加させていただける運びとなりました．
初めての渡米，初めてのIETF Meetingということで，可能な限りの情報をここに残しておきたいと思います．
このページでは，本イベントにおけるメインコンテンツWorking Group Meetingsに関する情報を記します．
なお，本記事は気になる箇所だけをかいつまんでご覧になることをおすすめします．
次のVol.ではPlenaryにて多様性尊重に関して考えたことを記し，その後にはFisherman's Wharf観光などについて記す予定です．
その他の記事は以下よりご覧いただけます．
WG Meetings
いよいよIETF Meetingのメインコンテンツ，WG(Working Group)ごとの会合が始まります．
気になったものを抜粋してまとめてみました．
と，その前に，今回初めて対面でRFCの議論の場に参加して，どのように内容を理解したのか，どのようなことを感じたか簡潔に示します．
- 基本的にはHedgeDoc(リアルタイムで記される議事録)を段落ごとに翻訳して雑感を把握します．
- 書いてくださる方によって，理解のしやすさには結構揺れがあります．
- 関連する技術について調べながら，まとめてゆきます．
- 会場が沸いたときには，MeetechoのCCを適宜翻訳して理解の支えにします．
- 自分で有効化しないと表示されず，有効化前のCCは表示されないので要注意です．
- 特にWi-Fiが落ちてリロードしたときに忘れやすい．
- 英語を母国語レベルですんなり理解できる人と比べ，あくまで私の場合ですが発表内容の理解には概ね2倍程度の時間を要すると感じました．
- 1セッション中，2件目の発表が終わる頃にようやく1件目の趣旨が理解でき，質問が湧いてくる，といったイメージです．
- 無論，これは経験値や英語力，技術力によって多分に左右されます．
- 聞き取ることができても，そもそもの技術や背景を把握しきれていなければ喋っていることを"理解"することはできない
- プログラムコードは共通言語．
- これはJPNICの木村様より事前に教えていただいていたことですが，
ある程度方向性が固まっているDraftについては(他と比べて)盛り上がるような発表・議論は行われませんでした．- 序盤〜中盤くらいのものだと，よりリアル参加のメリットを享受できるなと感じました．
- 目安として，発表時間20分程度の枠でしょうか．
- 序盤〜中盤くらいのものだと，よりリアル参加のメリットを享受できるなと感じました．
以降，大見出しがWG名，中見出しが発表タイトルです．
簡単な日本語タイトルも添えています．
Domain Name System Operations
Updates on draft-ietf-dnsop-cds-consistency
日訳：IETFドラフト，Consistency for CDS/CDNSKEY and CSYNC is Mandatoryに関する最新情報
Compact Denial of Existence in DNSSEC
日訳：DNSSECにおける処理負荷の小さな不在証明
https://datatracker.ietf.org/meeting/117/materials/slides-117-dnsop-compact-denial-of-existence-01
NXDOMAINを利用するか，ENTシグナルを利用するか，いずれにも対応すべきか...
NS1：ENTを利用
Cloudflare：NXNAMEを利用
Authentication and Authorization for Constrained Environments
EDHOC (Ephemeral Diffie-Hellman Over COSE)
https://datatracker.ietf.org/meeting/117/materials/slides-117-lake-draft-ietf-lake-edhoc-00.pdf
COSE：CBORオブジェクトの署名・暗号化アルゴリズム
CBOR：RFC8949，データ交換フォーマットの1つ．JSONなどと違ってバイナリで表すため，バイナリデータをいちいちエンコードする必要がなく効率的．IoT向け．
Lightweight Authorization using EDHOC
日訳：EDHOCを用いた軽量な認証
COSE (CBOR Object Signing and Encryption)
セコムの磯部様による発表もございました．HPKE関連の発表があり，関心を抱く．
ACME (Automated Certificate Management Environment)
Automated Certificate Management Environment (acme) - HedgeDoc
QUIC
Multipath extension for QUIC
https://github.com/quicwg/wg-materials/blob/main/ietf117/multipath.pdf
マルチパス実装がすでに5つあり，相互接続性についての検証を実施中．
PATH_STATUSはavailable, standbyの2つだが，本当にこれで良いのか
→前回のミーティングから新しい情報はない．これ以上増やすと冗長．
エラーコードが1つだけだが，よいのか
→理由はreason領域で示せばよい．ここでこれ以上増やすべきでない
→デバッグ用にあってもよいのでは
→週末にもう少し詳しく話そう
PATHをコネクションから分離させては(パケットNo. を含むQUICパス)
→あまりに破壊的な変更
→アイドル状態のコネクションにより，メモリが圧迫される
→続きはGitHubで
経路と暗号化キーに関しては分けて考えるべきとの声
(複数のencryptコンテキストがあると，メモリの使用量が大幅に増加する)
Resetting and Closing Streams
https://github.com/quicwg/wg-materials/blob/main/ietf117/reliable-resets.pdf
RESET_STREAMフレームを送信すると，当該ストリームではデータは再送されない．
これに対して，ロスデータの再送は行わせるのが今回の提案
あらゆる再送を受け付けるわけではなく，CLOSE_STREAMフレームで許容する量を示す
- RESET_STREAM：一切受け付けない
- CLOSE_STREAM：以降，指定した量の再送を許容する
- STREAM (with FIN bit)：まだまだ受け付ける
フレームタイプサイズは1byteでよいか
→1でよい．2でもよいがそんなに使わない
適用したv2を作ってプラハに持っていく
思っていたより早く実装/相互接続の検証が行われていて驚いている，よい．
Post-Quantum Use In Protocols
最近流行りのポスト量子(耐量子)系ですね．
Post-Quantum Cryptography for Engineers
日訳：耐量子暗号入門
PQCを理解するための，大変分かりやすいなと感じた資料です．
IETF117-PQUIP-20230725-2000 - YouTube
上記動画でCCをつけてご覧になると，より理解しやすいかもしれません．
Post-Quantum Cryptography at Google
日訳：Googleにおける耐量子暗号の運用状況
Terminology for Post-Quantum Traditional Hybrid Schemes
日訳：耐量子暗号と従来の暗号のハイブリッドスキームに関する記述について
https://datatracker.ietf.org/meeting/117/materials/slides-117-pquip-pqt-hybrid-terminology/
Crypt Forum
A Modest Proposal for HPKE
日訳：HPKEへのささやかな提案
https://datatracker.ietf.org/meeting/117/materials/slides-117-cfrg-deterministic-nonce-less-hpke/
TLS (Transport Layer Security)
A well-known URL for publishing ECHConfiLists
日訳：ECH Config Listを取得するための Well-known URL
https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-draft-ietf-tls-wkech/
ECHを利用するとき，クライアントはpublic-name(カバーするホスト名)とprivate-name(真にアクセスしたいホスト)を用いる．
クライアントがpublic-nameを何にするとよいかはサーバによって提供されるech-configに格納されている．
これはDNSのHTTPSレコードで取得する．(A, AAAAレコードのWebサーバ向け拡張版？)
例えば，「https://draft-13.esni.defo.ie/.well-known/origin-svcb」で取得できるように統一しないか？
ECH SVCBドキュメントにマージするべき？
→誰も はい と言わず
ALPNはまだ修正されるかもしれない
(Webサーバの)同じDocRootからの異なるECHをサポートしないように編集する
443以外のポートでも動作するよう，Issue #12に対処する予定
次のドラフトが最終になるだろう．しかし，まだ作業する予定
このドラフトを認めるかの投票 → ほぼOK
ECH Update
https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-ech-update/
ECH：Encrypted Client Hello
TLS 1.2 is frozen
https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen/
とてもわくわくさせてくれるタイトルですね．
以下，聴講時のメモです．
TLS 1.2を凍結しよう
- 新しいアルゴリズムを追加しない
- ALPN, Key Exporterラベルは追加可能
- それ以外の新しいエントリは認めない
- 新しい技術はTLS 1.3以降用であることを示そう
- すなわち，耐量子技術はTLS 1.2では実装されない．
他のプロトコルへの影響
反応
- not “MUST TLS 1.3”, “MUST TLS 1.3 or newer”
1.3と示されたすべてを書き換える必要があるね - TLS 1.2に致命的な欠陥が見つかったら，IETFはどうする？
わからない，1.2を使うのをやめると言うかもね - WGの”感情”を外に伝える，よいdraft
- TLS 1.2への機能追加を予定していないことを示すには，
「frozen」は「do not touch」よりも適した表現だね - TLS 1.2の機能に依存している企業が，新しい機能を必要としたときに拒否される
- 一部の機能は1.2から動けず，1.2をサポートしなければならない現状がある
それらの企業が1.3に移行するには，まだ時間を要する - 現在の検証で，既にTLSの古いバージョンへの更新を禁止している．RFCは必要なのか？
- Enterpriseはなかなか移行しないよ x N人
- だからこそ，このRFCがいる
- 「あなた達は移行しなければならない，価値が下がる」と伝えることに意味がある
57件の投票に対し，14件の反対
新しいドラフトを書いて，リストに確認します．とのこと，
New Post-Quantum Signatures on the Horizon
日訳：新しい耐量子署名アルゴリズム
利用しやすい完璧な耐量子署名アルゴリズムはまだ存在しない．
ただ，いくつかのスキームはTLS/WebPKIに移行するより容易に利用可能
まだまだ多くの検討が必要
詳細：Post-Quantum signatures zoo
HTTP about using exported authenticators
これに関しては，予定されていた発表が一通り終わった後に「今思いついたんだけどさ」と口頭で発表・議論が始まりました．
こういったことが起きるのが面白いですね．
概要だけ示します．
Exported Authenticators in TLSについて，クライアントがサーバーから証明書を要求されずに証明書を送信できるようにするのはどうだろう
反応
- Exported Auth in TLSには unpromotedモードがあったが，削除した．
必ずしも不可能ではないだろうが，削除したのには理由がある． - early dataで送信されると，クライアント証明書が漏洩する．それはよくない
Abridged Certs
日訳：証明書の要約
SAAG (Security Area Open Meeting)
Lessons from ACME
https://datatracker.ietf.org/meeting/117/materials/slides-117-saag-lessons-from-acme/
WHODIS (Wholistic Human-Oriented Discussions on Identity Systems)
https://datatracker.ietf.org/meeting/117/materials/slides-117-saag-whodis/
MLS (Messaging Layer Security)
祝，RFC9420！！
冒頭でシャンパンが配られました．
-mls-addl-creds
https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-mls-addition-credentials/
現状のクレデンシャル
- 0x0000 reserved
- 0x0001 basic
- 0x0002 x509
提案
- 0x0003 userinfo-vc
- 0x0004 multi
- 0x0005 weak-multi
userinfo-verifiable credentials
資格情報の新しい形式．ユーザに認証情報をより簡単に発行する方法
https://www.w3.org/TR/vc-data-model/ VCフレームワークに基づき，OpenIDプロバイダがMLSと互換性のある資格情報を発行できるようにする．
例えば，Webexミーティングを開催しているとき，MLSを利用してユーザの資格情報を提示できるようになる．
相手側企業のSSOプロバイダに直接聞くため，Webexが何者かになりすましていないことがわかる．
multi, weak-multi
他のタイプの資格情報をいくつか組み合わせて，単一グループ内の単一クライアントに対して複数の資格情報を提示できるようにする仕組み．
特定のセッションで同一のクライアントに対し複数の資格情報を提示したい場合がある．
例えば，このハンドルネームを有していることを示す証明書，
この電子メールを所有していることを示すVC資格情報，といったように．
multi：すべてのクレデンシャルをサポートしなければならない
weak-multi：いずれか1つのクレデンシャルをサポートしなければならない
反応
- 循環参照に陥らないか？
→ multi-in-multiを禁止すべきだね
反対0
Lots of Proposed MLS Extensions
日訳：たくさんのMLS拡張に関する提案
https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-lots-of-proposed-mls-extensions/
MLS Extensions
https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-status-on-mls-extensions/
一通りのupdate．
Gurdianship for MLS
https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-guardianship-for-mls/
HTTP (Hyper-Text Transfer Protocol)
Discovering WebSockets over HTTP/2 and HTTP/3 Design Team Report
日訳：HTTP/2，3におけるWebSockets
https://datatracker.ietf.org/meeting/117/materials/slides-117-httpbis-websockets-design-team-report/
Secondary Certificate Authentication of HTTP Servers
日訳：Webサーバにおける2つ目の証明書認証
DMARC (Domain-based Message Authentication Reporting and Conformance)
Food For Thought
日訳：議論のために．
https://datatracker.ietf.org/meeting/117/materials/slides-117-dmarc-ad-slides/
DMARC WGができてから9年経った．
成果を上げていないWGを終了する圧力が高まっている．
次のエリアディレクターはもう我々の活動を認めないかもしれない
このWGのエネルギーを他のプロジェクトに費やしたほうがよいのではないでしょうか．
「我々のWGは役目を全うしたのではないか」
WG Meetingについてはひとまず以上です．
続きはこちら．
