要約

  • IESGは2026年9月3日、TLS/DTLS 1.3 Profiles for the Internet of Thingsの第25版をProposed Standardとして承認した。発表時点では最終RFC番号は付いていない。
  • 文書はRFC 7925を補完し、X.509証明書プロファイルと暗号スイート要件だけを更新する。長寿命のTLS/DTLS 1.2設備を無効にするものではない。
  • 本文は、TLSプロトコル互換性が必要な土台であっても、認証と認可の相互運用には不十分だと明記する。
  • 証明書、raw public key、外部PSKは、本人性の結合と運用責任を異なる場所へ置く。ハンドシェイク成功はローカルな操作許可を意味しない。
  • 事業者は、資格情報方式、期待する相手、認可規則、trust anchor、セッション年齢、再認証、エラー時動作、切り戻しを結ぶ版管理済みの境界記録を残すべきだ。

共通仕様が決めたこと

今回のProtocol Actionは、単なる勧告記事の公開ではない。Using TLS in Applications Working Groupがまとめた文書を、IESGが標準化トラックのProposed Standardとして承認した。制約のある機器向けに、TLS 1.3とDTLS 1.3の資格情報、拡張、警報、再開、forward secrecy、タイマー、レコード長、証明書、暗号スイートを一つの実装基準へ整理している。

IoTでは「TLS 1.3対応」という表示だけでは相互運用できない。メモリや無線容量を理由に必要拡張を削り、証明書の意味を別々に解釈すれば、双方が準拠を主張しても接続条件は合わない。プロファイルはこの曖昧さを減らす。

同時に第25版は、自らの権限の終点を記す。プロトコル互換性は認証と認可の相互運用を保証しない。暗号処理が確認するのは、ある文脈で鍵を保持する相手である。運用者が判断するのは、その鍵が予定した機器に属するか、その機器が当該アプリケーションで何をしてよいかである。

文書状態にも段階がある。承認済みProposed Standardであり、RFC Editorの作業と最終番号はこれからだった。Internet Standardでも製品認証でもない。この区別は承認を軽くするためではなく、制度上の決定、出版物、実装証拠を混同しないために必要だ。

RFC 7925も消えない。新文書が更新するのは証明書と暗号スイートの部分であり、TLS/DTLS 1.2の既存プロファイルは旧設備で引き続き意味を持つ。工場認証や保守周期が長い現場では複数世代が共存する。どの機器がどの版に従うかを記録しなければ、移行は名称だけになる。

三つの資格情報は同じ信頼ではない

文書はX.509証明書、raw public key、外部PSKという三方式を扱い、唯一の方式を強制しない。安全特性、費用、機器能力、保守方法に応じて選択が変わるからだ。

証明書は発行チェーンの下で公開鍵と識別子を結ぶ。第25版は製造時のIDevIDと運用時のLDevIDを分ける。前者は初期オンボーディングの足場になり、後者は所有者や運用者のドメインで使われる。製造者の長期識別子を、更新が面倒だからという理由で恒久的な運用権限に変えてはならない。

raw public keyは証明書の転送量を省ける一方、期待する相手との結合を導入側が用意する必要がある。固定鍵、固定証明書、設定済みアドレス、PSK識別子などを理由にSNIを送らない場合も、別の結合が要る。鍵の検証に成功しても、それを誤ったサービスへ割り当てればmisbindingは残る。

外部PSKは意味の多くを帯域外プロビジョニングへ移す。識別子、十分なエントロピー、利用ドメイン、TLS世代間の分離、交換手順を管理しなければならない。プロファイルは可能な場合に(EC)DHEを使うよう求め、PSK-onlyはforward secrecy喪失を当該展開で明示的に受け入れた場合だけ認める。その受容には責任者と期限が必要だ。

SNIはサーバーの文脈を、ALPNはアプリケーション・プロトコルを選ぶ助けになる。しかし認可は、認証済み資格情報とローカル・ポリシーによって決まる。プロトコル名が一致しても、コマンドの実行権は生まれない。

失効処理を省けば、運用者の時計が始まる

制約機器はハンドシェイク中にOCSPやCRLを確認する資源を持たないことが多い。文書はその場合、短寿命の運用証明書、自動オンボーディング、管理機構による更新を基本に置く。失効の必要性を消すのではなく、その実行主体を上位へ移す設計だ。

ここで長期セッションが問題になる。証明書を交換しても、すでに成立したTLS接続は自動では終わらない。TLSは接続後の継続的な有効性確認を義務付けない。継続確認が必要なら、アプリケーションが再認証を起動するか、切断して接続し直す必要がある。相互のpost-handshake認証にはアプリケーション・プロトコル側の仕組みも要る。

したがって「新証明書を配布済み」と「旧資格による権限が終了」は別の状態である。両者の間に残るセッションを計測しなければ、失効処理の完了時刻は分からない。

trust anchorはさらに長い。数年稼働する機器はCAの切り替え、メーカー変更、アルゴリズム移行、事故対応をまたぐ。ファームウェア更新や証明書管理は新しいanchorを運べるが、配布は選択を証明しない。計画、到達、導入、有効化、観測、旧anchor廃止を別々に残す必要がある。

小さいパケットほど周辺の証拠が重要になる

第25版の最小例では、ECC証明書を使い中間CAを置かない相互認証でも、二つの証明書がTLS 1.3ハンドシェイク・ペイロードの約40％を占める。短いチェーン、圧縮、キャッシュ、セッション再開には明確な価値がある。

ただし、再開ticketの数、有効期間、再利用は、帯域と計算量だけでなくサーバー状態、replay、privacyを動かす。証明書の外部取得は通信量を減らす代わりにDNSやdirectoryへ依存し、安定識別子を取得先へ見せる可能性がある。キャッシュには失効判定が要る。省資源は別の制御面を必要とする。

0-RTTの扱いは境界の好例だ。安全なメッセージと拒否時の1-RTTへの戻り方を定めたアプリケーション固有プロファイルがなければ使ってはならない。第25版作成時点でCoAPとMQTTにはそのプロファイルがなく、本書は0-RTTを有効にしない。ライブラリが早期データを送れることと、アプリケーションが送ってよいことは違う。

エラー処理も同じである。無人機器は利用者へ判断を求められない。再試行、別endpoint、別資格情報、degraded mode、安全停止のどれを選ぶかはアプリケーションが前もって決める。TLS alertは入力であり、現場結果の決定ではない。

認可境界を記録する

必要なのは証明書全文や設定dumpではない。まずプロファイル版と実装buildを示し、資格情報方式、安定参照、期待するpeer、結合方法、アプリケーション・プロトコルと役割、ローカル認可規則の版、許可・拒否する操作クラスを結ぶ。

ライフサイクル欄にはanchor世代、証明書またはPSK世代、配布経路、有効化の観測、期限、交換状態を置く。セッション欄ではfull handshakeとresumptionを分け、ticket世代、開始時刻、最終再認証、最大寿命を記録する。forward secrecyの例外には所有者、範囲、失効日を付ける。

安全欄は重要alertを再試行、代替、縮退、安全停止へ接続する。0-RTTは無効と記すか、将来のプロファイルが許した場合は対象messageとanti-replay状態を明示する。秘密鍵、内部名称、詳細topology、攻撃手順は公開対象にしない。

状態変更は上書きせず追記する。現在の認可表だけでは、昨日開いたセッションがどのanchorと規則で通ったか説明できない。履歴は監視の飾りではなく、過去の権限を解く鍵である。

Heng LuのNote 64は、ここでは限定的な編集原則として使える。共有仕様は最小で決定的、かつ各現場で検証可能であるべきだ。このノートは特定展開の証拠ではない。共通規則がローカル判断を奪わないことと、ローカル判断が標準の名に隠れないことを同時に要求する。

承認からは言えないこと

資料は、特定製品の準拠、特定fleetの移行、侵害や事故を証明しない。IESGはCA、PSK、権限表、安全停止を選んでいない。Proposed Standardは製品の安全証明書ではない。

PQC節も境界が明確だ。規範的暗号スイートは古典暗号であり、PQCの記述はinformationalで新しい要件を加えない。機器寿命の長さは移行計画を必要にするが、量子耐性を現在形にはしない。

また、すべての制約機器がOCSPやCRLを絶対に実行できないとも書いていない。一般的な制約を踏まえ、ケースごとに安全と複雑さを評価する。能力がある環境は別の選択をできる。

この承認の強さは、残った責任を曖昧にしないところにある。IETFは接続の共通基準を与えた。機器へ許可を与える者は、なお現場で結果を引き受ける主体である。

情報源

  1. IESG：IoT向けTLS/DTLS 1.3プロファイルのProtocol Action
  2. IETF：承認された第25版
  3. RFC 9846：TLS 1.3
  4. RFC 9147：DTLS 1.3
  5. RFC 7925：IoT向けTLS/DTLSプロファイル
  6. RFC 5280：X.509 PKIプロファイル
  7. RFC 9257：外部PSKの指針
  8. RFC 9258：外部PSKのimport
  9. RFC 9019：IoT機器のfirmware update
  10. RFC 8995：BRSKI
  11. RFC 9525：TLSのservice identity
  12. RFC 9325：TLS/DTLSの安全な利用
  13. Heng Lu：Minimum Initial Specification