こんばんは！
GMOコネクト 執行役員CTO 菅野 哲（かんの さとる）です。
タイトルにあるTLS 1.3 の更新版が発行されたので、今までのプロトコルとどこが違うのか気になるなぁ〜ということでまとめてみました。
はじめに
2026年7月、TLS 1.3 の仕様が RFC 9846 として再発行されました。TLS 1.3 といえば 2018年の RFC 8446 がおなじみですが、それを obsolete（廃止・置き換え）する新しい RFC が出たことになります。
ただし勘違いしてはいけないのは、これは「TLS 1.4」でも「TLS 1.3.1」でもないということです。プロトコルのバージョン番号は 1.3 のまま、そして 既存の RFC 8446 実装と後方互換です。IETF の TLS ワーキンググループが draft-ietf-tls-rfc8446bis（2020年10月の draft-00 から 2025年9月の draft-14 まで）として時間をかけて磨いてきた、いわゆる「bis（改訂版）」です。
では何が変わったのでしょうか。新しい暗号方式や新しいハンドシェイクモードの追加はありません（general_error アラートの新設など小さな追加はあります）。変更は大きく4種類に整理できます。(A) セキュリティ要件の厳格化、(B) アラート挙動の明確化、(C) 構文（長さ境界）の誤り訂正、(D) ポスト量子と将来仕様への対応。そして、この4つを貫くのが (E) 用語の変更（master → main）です。RFC 9846 の §1.2「Relationship to RFC 8446」に、著者の Eric Rescorla 自身が15項目の変更リストを載せています。これを一次資料（RFC 9846 と RFC 8446 の全文）と突合しながら順に見ていきます。
全体像（3行サマリ）
- バージョンは 1.3 のまま・後方互換。RFC 8446 を obsolete し、TLS 1.2 系の複数 RFC も本文に吸収しました。
- 中身は「要件の厳格化」「長さ境界の誤り訂正」「用語 master→main」「KEM 対応の一般化」。新しい暗号方式やハンドシェイクモードの追加はありません。
- 最大の注意点です。master→main は名称変更だけで、鍵導出のラベルバイト列は据え置かれます。だから鍵スケジュールは wire 互換で壊れません（後述）。
文書としての変化：何を統合したか
ヘッダの Obsoletes を並べると、この改訂が何を整理したのかが見えてきます。
| RFC 8446 (2018-08) | RFC 9846 (2026-07) | |
|---|---|---|
| Obsoletes | 5077, 5246, 6961 | 5077, 5246, 6961, 7627, 8422, 8446 |
| Updates | 5705, 6066 | 5705, 6066 |
新たに obsolete した3本は次のとおりです。
-
RFC 7627（TLS Session Hash / Extended Master Secret 拡張）… 本文に統合され、拡張名も
extended_master_secret→extended_main_secretに改称されました。 - RFC 8422（TLS 1.2 以前向けの ECC 暗号スイート）… 本文に統合されました。
- RFC 8446（TLS 1.3 本体）… 自分自身の旧版です。
つまり RFC 9846 は TLS 1.3 の書き直しだけでなく、周辺に散らばっていた TLS 関連 RFC の整理も兼ねています。
(A) セキュリティ要件の厳格化
1. 鍵シェアの接続間再利用を禁止
TLS 1.3 のハンドシェイクでは、クライアントとサーバが key_share として一時的な公開値（基本仕様では (EC)DHE の公開値。KEM を使う鍵交換は別の拡張が定義します）を交換します。RFC 8446 はこの値を複数接続で使い回すことを許容していました。RFC 9846 はこれを禁止します。
Clients and Servers MUST NOT reuse a key share for multiple connections.
やめる理由は主に2つです。1つは前方秘匿性（forward secrecy）で、鍵シェアに対応する秘密鍵を使い回すと、その1本が漏れたときに、それを使った全接続の鍵がまとめて破られます。もう1つは接続の相関（linkability）で、RFC 9846 も別の箇所で「チケットや鍵シェアが再利用されると passive observer が接続を相関づけられる」と述べています。ただし禁止規定そのもの（§4.3.8）には理由が併記されていないので、上の2つは根拠づけの説明です。接続ごとに新しい鍵シェアを生成すれば、いずれのリスクも1接続に閉じ込められます。
ここで面白いのは後方互換の作法です。RFC 8446 は再利用を許していたので、旧実装は再利用してくる可能性があります。そこで RFC 9846 は「送る側は使い回すな（MUST NOT）／受ける側は相手の使い回しを許容せよ（MUST permit）」という非対称なルールにしました。これは §4.3.8 に "Because [RFC8446] permitted reuse, receiving implementations MUST permit reuse by the peer in order to prevent interoperability issues" と明記されています。新旧が混在しても通信は壊れません。
図1: 鍵シェア再利用の非対称ルール。送信側は再利用禁止（MUST NOT）、受信側は相手の再利用を許容（MUST permit）します。再利用は前方秘匿性を損ない、接続の相関（linkability）も招くため避けます。
2. TLS 1.0 / 1.1 のネゴシエーションを禁止
TLS 1.0 と 1.1 は RFC 8996（BCP 195, 2021年）で正式に deprecate 済みです。RFC 9846 はこれを仕様本文に取り込み、これらのバージョンへのネゴシエーションを禁止しました。TLS 1.3 の実装が古いバージョンにフォールバックする余地を閉じます。
3. PSK・HelloRetryRequest で使うハッシュの曖昧さ除去
RFC 8446 では、PreSharedKey や HelloRetryRequest に絡む処理で「どのハッシュ関数を使うのか」が読み手によって解釈の割れる箇所がありました。RFC 9846 はこれを一意に規定し直しました。相互運用性のための、地味ですが重要な明確化です。
4. resumption 非対応クライアントは NewSessionTicket を無視する
セッション再開（resumption）を実装しないクライアントが NewSessionTicket を受け取ったときの挙動を明確化し、「無視してよい」と規定しました。
5. 鍵使用量の上限前に、鍵更新を「SHOULD」から「MUST」へ
同じ鍵で AEAD 暗号化を続けられる量には、安全性解析に基づく上限があります。RFC 8446 の書きぶりは次のとおりでした。
Implementations SHOULD do a key update … prior to reaching these limits.
RFC 9846 はこれを格上げします。
Implementations MUST either close the connection or do a key update … prior to reaching these limits.
具体的な数字も示されています。AES-GCM なら1鍵あたり最大 2^24.5（約2,400万）レコードまで、安全マージン約 2^-57（AE セキュリティ）を保てます。ChaCha20/Poly1305 では、安全上限に達する前にレコードのシーケンス番号がラップします。なお、この 2^24.5 という数値自体は RFC 8446 から変わっていません。RFC 9846 が変えたのは「上限前に鍵更新すべき」の強制度（SHOULD → MUST）とスコープの明確化です。
さらに、early data（0-RTT データ）は KeyUpdate ができないという性質があるため、early data 送信時はこの上限を超えてはならない（MUST NOT）という制約も明文化されました。なお受信側はこの上限を強制すべきではありません（SHOULD NOT）。将来の解析で値が更新される可能性があるからです。
6. KeyUpdate メッセージの数を制限
KeyUpdate は通信中に鍵を更新するメッセージで、request_update が update_requested なら相手も更新を返します。ここに素朴な実装だと、相手に何度も KeyUpdate を投げつけて更新処理を強制する資源消費攻撃の余地がありました。
RFC 9846 は「相手からの次の KeyUpdate を受け取るまで、update_requested 付きの KeyUpdate を追加で送ってはならない（MUST NOT）」と定めました。沈黙中に複数の KeyUpdate を受けても、応答は1回にまとめられます。
併せて、鍵切替のタイミングに関する truncation（切り詰め）攻撃対策も再確認されています。送受信の鍵は独立した traffic secret から導出されるので受信鍵を保持しても前方秘匿性は損なわれないこと、そして「旧鍵で暗号化された KeyUpdate を受け取ってから新鍵のメッセージを受理する」ことを強制すること、が明記されました。
(B) アラート挙動の明確化
7. close_notify の level は「warning」
RFC 8446 では close_notify の AlertLevel が warning であるという記述が抜け落ちていました。RFC 9846 はこれを復活させました。
8. user_canceled の扱いを明確化
user_canceled について、「送るときは close_notify も送ること」「受け取った側は user_canceled を無視すべき」「level は warning」と整理されました。
9. 汎用アラート general_error を新設
特定の既存アラートに割り当てられないエラーを通知するための汎用アラート general_error(117) が追加されました。値 117 は IANA に新規登録されています。これまで「該当するアラートがない」場面で実装ごとにばらついていた挙動に、共通の受け皿を与えます。
(C) 構文の誤り訂正：長さ境界の計算ミス
TLS の仕様は構造体を独自の presentation language で定義します。そこにあった長さ境界の計算ミスが3件（§1.2 の項目10〜12にあたります）、まとめて直されました。いずれも相互運用に効くので、パーサを書く人は要チェックです。
| 構造体フィールド | RFC 8446 | RFC 9846 | 修正内容 |
|---|---|---|---|
ClientHello.extensions |
<8..2^16-1> |
<7..2^16-1> |
下限 8→7 |
CertificateRequest.extensions |
<2..2^16-1> |
<0..2^16-1> |
下限 2→0 |
NewSessionTicket.extensions |
<0..2^16-2> |
<0..2^16-1> |
上限 2^16-2→2^16-1 |
とくに CertificateRequest.extensions は、拡張を1つも持たない（＝長さ0）ケースが本来ありうるのに、下限が2になっていました。厳しすぎる下限チェックを入れていた実装は、正当なメッセージを弾いていた可能性があります。
(D) ポスト量子と将来仕様への対応
13. 非対称鍵交換の表現を一般化
RFC 8446 は非対称鍵交換を実質 (EC)DHE（有限体／楕円曲線上の Diffie-Hellman）に限って記述していました。RFC 9846 は、これを KEM（鍵カプセル化機構）ベースの鍵交換も含む一般的な表現に書き換えました。ML-KEM などポスト量子 KEM やハイブリッド鍵交換を、後続仕様が無理なく載せられるようにするためでしょう。ただし本文が特定の PQC RFC を名指ししているわけではなく、表現を広げているだけではあります。
14. transcript hash と将来仕様の相互作用を明確化
ハンドシェイクの記録ハッシュ（transcript hash）が、将来の拡張仕様とどう相互作用するかを明確にしました。
15. RSA-PSS を要求するテキストを削除
RFC 8446 は、ハンドシェイクの RSA 署名（主に CertificateVerify）に RSASSA-PSS を使うよう要求していました。ところが 2026年4月に RFC 9963「Legacy RSASSA-PKCS1-v1_5 Code Points for TLS 1.3」（D. Benjamin, A. Popov）が発行され、旧来の RSASSA-PKCS1-v1_5 のコードポイントが、TLS 1.3 の**クライアント証明書認証（client CertificateVerify）**向けに（レガシー HSM/TPM 互換目的で）割り当てられました。サーバ証明書検証や CertificateVerify 全般で PSS が不要になったわけではありません。
これに整合させるため、RFC 9846 は「PSS を要求する」テキストを削除しました。これは署名方式の話であって、(D) の見出しに置いたものの PQC とは無関係である点に注意してください（KEM 一般化の #13 と混同しやすいので明示しておきます）。仕様差分としては重要なので、PQC に関係なくても押さえておきましょう。
(E) 最重要：master → main 改称と、壊れない互換の仕掛け
RFC 9846 は、secret に付いていた "master"（マスター）という語を "main" に全面改称しました。master_secret は「main secret」に、拡張 extended_master_secret は extended_main_secret に、といった具合です。差別的含意のある用語を排する、近年の IETF 全体の流れに沿った変更です。
ここで身構えるのは、TLS の鍵導出（HKDF-Expand-Label）がラベル文字列をそのまま入力バイト列として使うという事実です。もしラベルの綴りが "master" から "main" に変われば、導出される鍵が変わり、旧実装と鍵が合わなくなります。つまり後方互換が壊れます。
RFC 9846 はそうしていません。鍵スケジュールの図に、次の注記が追加されました。
Note: The key derivation labels use the string "master" even though the values are referred to as "main" secrets. This mismatch is a result of renaming the values while retaining compatibility.
図2: 呼び名は変わりますが（main 化、または exporter/resumption のように短縮）、HKDF に渡す label バイト列は "master" のままなので、RFC 8446 実装との wire 互換性は保たれます。
実際、導出ラベルは Derive-Secret(., "exp master", …) や Derive-Secret(., "res master", …) のように、バイト列としては "master" のまま据え置かれています。呼び名は「main secret」に変えましたが、ワイヤ上のラベルは「master」のままです。だから RFC 8446 実装と RFC 9846 実装は問題なく相互運用できます。
この改称は TLS 1.3 の secret だけに留まりません。RFC 9846 は TLS 1.2（RFC 5246）を obsolete して本文に吸収したため、そちら由来の用語にも同じ原則が適用されます。master secret → main secret、premaster secret（pre_master_secret）→ preliminary secret、構造体 PreMasterSecret / EncryptedPreMasterSecret → PreliminarySecret / EncryptedPreliminarySecret、そして RFC 7627 の「Extended Master Secret」拡張 → 「Extended Main Secret」（コードポイント名 extended_master_secret → extended_main_secret）。いずれも呼び名は変えますが、PRF/HKDF に渡す label のバイト列は互換のため据え置くという一貫した方針です。
「用語を master→main に変えた」という一文だけを読んで「じゃあラベルも変わって非互換になるのでは」と早合点すると、真逆の結論に着地してしまいます。名称は変わりましたが、wire は変わっていません。ここが本改訂で一番取り違えられやすいところです。
なお、セキュリティ考慮事項（Security Considerations）も、とくにプライバシーの観点で加筆・改善されています。
TLS 1.2 だけの実装にも効く変更（§1.4 新設）
RFC 9846 は「Updates Affecting TLS 1.2」という節（§1.4）を新設し、TLS 1.3 を実装しない TLS 1.2 専用実装にも影響する項目を明示しました。
- バージョンダウングレード保護機構（§4.2.3）
- RSASSA-PSS 署名方式の定義（§4.3.3）
-
supported_versions拡張によるバージョンネゴシエーション（legacy_versionフィールドより優先） -
signature_algorithms_cert拡張（証明書検証に使える署名アルゴリズムの提示） -
extended_master_secret拡張（RFC 7627）→extended_main_secretへ改称 - TLS 1.2 以前のコンプライアンス要件の明確化（§9.3）
TLS 1.2 を保守している人も、この節だけは目を通しておく価値があります。
実装者は何をすべきか
最後に、実装・運用の観点でチェックリストにまとめます。
- 互換性：バージョン番号も鍵スケジュールの wire フォーマットも不変です。既存 8446 実装との相互運用性は保たれます。恐れず追随して大丈夫です。
- 挙動の必須変更：①鍵シェアを接続間で使い回している実装は停止します。②鍵使用量の上限前に必ず鍵更新（またはクローズ）します。③KeyUpdate を連発しません。
-
新規識別子：
general_error(117)アラートを実装・処理できるようにします。 -
パーサ：
CertificateRequestとClientHelloの拡張長の下限チェックが厳しすぎないか見直します。 - ドキュメント整理の把握：RFC 7627 と 8422 が本文に統合されました。参照している仕様書のリンク先を更新します。
まとめ
RFC 9846 は派手さのない改訂です。新しい暗号も新しいハンドシェイクも増えません。それでも、8446 の運用で見つかった曖昧さや誤り、危うい緩さ（鍵シェア再利用、SHOULD 止まりの鍵更新、KeyUpdate 連発）を、後方互換を保ったまま一つずつ直しています。KEM ベース鍵交換への表現一般化で、ポスト量子時代への下地も整えました。
プロトコルは同じ 1.3 のまま、緩かった要求が MUST に締まり、抜け道がふさがれました。それが RFC 9846 です。
参照
- RFC 9846：The Transport Layer Security (TLS) Protocol Version 1.3（2026-07、本記事の主対象）
- RFC 8446：同上（2018-08、旧版）
- RFC 8996：Deprecating TLS 1.0 and TLS 1.1（BCP 195）
- RFC 7627：Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension（9846 が統合・改称）
- RFC 8422：Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier（9846 が統合）
- RFC 9963：Legacy RSASSA-PKCS1-v1_5 Code Points for TLS 1.3（2026-04、#15 の根拠）
先端技術に関する調査からプロダクション品質のシステム開発まで幅広くお力になれます。
お気軽にお問い合わせくださいませ。
本記事に関するお問い合わせは、GMOコネクトお問合せフォームよりお願いいたします。
https://gmo-connect.jp/contactus/