インターネット技術タスクフォース（IETF）は、Transport Layer Security（TLS）プロトコル バージョン1.3 を規定する新しい標準トラック文書 RFC 9846 を公開した。著者は TLS 1.3 の当初仕様と同じ Eric Rescorla 氏。この文書は 2018年8月に公開された RFC 8446 を廃止（obsolete） し、あわせて TLS 1.2 以前に関する RFC 5077／5246／6961／7627／8422 も廃止、RFC 5705／6066 を更新する。ドラフト段階では "RFC 8446bis" として知られていたものだ。

重要な点として、これは TLS 1.3 のバージョン番号そのものは変わらない（0x0304 のまま）マイナーアップデートであり、既存実装との後方互換性が保たれる。プロトコルの全面刷新ではなく、8年間の運用で判明した曖昧な記述の明確化と、いくつかの要件の厳格化が主眼となっている。

・セキュリティ上の主な変更点

RFC 9846 は「RFC 8446 との関係」の節で、具体的な技術変更を列挙している。セキュリティ運用の観点で注目すべきものは以下のとおり。

・KeyShare 値の再利用を禁止 
接続間での KeyShare 値の再利用が明確に禁止された。RFC 8446 では再利用が許容されていたため、相互運用性の問題を避けるべく、受信側は相手による再利用を引き続き許容しなければならない（MUST permit）とされている。鍵共有パラメータを使い回さないことは前方秘匿性（forward secrecy）の観点で望ましい。

・TLS 1.0 / 1.1 のネゴシエーションを禁止
RFC 8996 によって既に非推奨（deprecated）とされている TLS 1.0 および 1.1 を、TLS 1.3 実装がネゴシエートすることが明示的に禁止された。

・鍵更新（Key Update）要件を MUST に格上げ
鍵使用量の上限を超える前に鍵更新を開始する要件が、従来より強い「MUST」に格上げされ、鍵使用量上限の適用範囲も明確化された。さらに、許容される KeyUpdate メッセージの回数に上限が設けられ、無制限な KeyUpdate を悪用した攻撃の余地が塞がれた。

・PSK と HelloRetryRequest におけるハッシュの曖昧さを解消 
事前共有鍵（PreSharedKey）および HelloRetryRequest でどのハッシュが使われるかについての曖昧さが取り除かれた。

・セッションチケット処理の厳格化 
再開（resumption）をサポートしないクライアントは、NewSessionTicket を無視することが求められるようになった。

・アラート挙動の明確化 
close_notify のレベルを「warning」と定義する記述が復活。user_canceled の扱いが明確化され、close_notify の送信が求められると同時に user_canceled は無視すべきとされた。加えて、汎用アラート general_error が新設された。

・プライバシーとポスト量子への布石
RFC 9846 ではセキュリティ考慮事項、とりわけプライバシーに関する記述が改善されている。
また、鍵交換に関する記述が従来の (EC)DHE 専用の表現から、KEM（鍵カプセル化メカニズム）ベースの鍵交換も想定した、より一般的な言い回しに改められた。これは、NIST が標準化した ML-KEM や ML-DSA といったポスト量子暗号を TLS 1.3 に組み込む一連の作業（現在も IETF TLS ワーキンググループで進行中）と歩調を合わせるものだ。RFC 9846 は、これら後続仕様が参照する新たな基盤文書となる。

・用語の変更 ── "master" から "main" へ
技術的挙動には影響しないが、運用者やライブラリ開発者が把握しておくべき変更として、秘密値に対して用いられてきた "master"（マスター）という語が廃止され、"main"（メイン）またはより短い名称に置き換えられた。これに伴い、extended_master_secret 拡張は extended_main_secret に改称されている。

・ダウングレード保護の再確認
RFC 9846 は、TLS 1.3 のサーバー Random 値に埋め込まれたダウングレード保護メカニズムを引き続き規定している。TLS 1.3 サーバーが TLS 1.2 をネゴシエートする場合、Random 値の末尾8バイトを特定の値（44 4F 57 4E 47 52 44 01、ASCIIで "DOWNGRD" + 01）に設定しなければならず、クライアント側はこの値を検出した場合にハンドシェイクを中断する。これは能動的攻撃者によるプロトコルのダウングレードを検知するための仕組みだ。

・TLS 1.2 実装への影響

注目すべきは、この文書が TLS 1.3 を実装しない TLS 1.2 のみの実装に対しても新たな要件を規定している点だ。バージョンダウングレード保護、RSASSA-PSS 署名スキーム、supported_versions 拡張によるバージョンネゴシエーション、signature_algorithms_cert 拡張などが、TLS 1.2 実装にも関わる形で整理されている。

実務者への示唆
•    既存の TLS 1.3 接続は影響を受けない。 バージョン番号は据え置きで後方互換のため、ただちに接続が壊れることはない。
•    ただし ライブラリ更新時には、厳格化された MUST 要件（KeyShare 再利用禁止、鍵更新の強制、KeyUpdate 回数制限など）への準拠が求められる。OpenSSL、BoringSSL、Rustls などの主要実装がどう追随するか、リリースノートの確認が推奨される。
•    用語変更（master → main）に依存したコードや設定がある場合は、拡張名の改称に注意。
•    ポスト量子暗号への移行を計画している組織にとって、RFC 9846 は今後の ML-KEM／ML-DSA 対応仕様の参照基盤となるため、動向を追う価値がある。

________________________________________
出典
•    RFC 9846 "The Transport Layer Security (TLS) Protocol Version 1.3"（IETF、標準トラック、2026年7月） — IETF Datatracker: https://datatracker.ietf.org/doc/rfc9846/
•    RFC Editor: https://www.rfc-editor.org/info/rfc9846
注：本記事は公開された RFC 9846 の一次資料に基づく。IETF Datatracker および RFC 本文の記載日は2026年7月。一部のアグリゲータには2025年12月と表示されるものもあるが、権威ある一次情報源の日付を採用した。

記載者：片山　昌樹（セキュリティ＆マネージド事業部 アイズオンフォレンジックチーム）