TLSハンドシェイクでは、サーバはエンドエンティティ証明書と任意でルート証明書までたどるための中間証明書を送信します。
不要であればこの中間証明書を送信しないようにする「Suppressing Intermediate Certificates in TLS」という提案がMartin Thomson氏より出されています。
以前、証明書を圧縮する提案仕様と合わせて使用できます。
asnokaze.hatenablog.com
TLSハンドシェイクのうちサーバが最初に送るデータ量を削減するのは以下のメリットが考えられます。
- パケットが後続しない状況でのロス検出が不利なためパケットが少ないにこしたことがない。
- QUIC, HTTP/3ではTLSハンドシェイクを利用するが、アンプ攻撃の増幅率をへらすことができる。
Suppressing Intermediate Certificates in TLS
「Suppressing Intermediate Certificates in TLS」の仕様中では、すべての中間証明書のリストは大きいが量は限られていると書かれています。
クライアントが完全な中間証明書のリストを持つことを想定しており、その場合は後述するTLSフラグ拡張を用いて0xTBD (未決定) の値を1に設定します。
このフラグを受け取ったサーバはエンドエンティティの証明書のみを送信します。
TLS Flags
クライアントやサーバがTLSの特定の機能をサポートしていることを示すのにTLS拡張が使用されてきました。
しかしTLS拡張は4バイトを使用します。フラグとして利用するのには少々もったいありません。
そこで別途提出されている「A Flags Extension for TLS 1.3」という提案では、フラグ領域をもつTLS拡張領域を定義しています。
このようになります。
enum { ... tls_flags(TBD), (65535) } ExtensionType;
クライアントが1に設定したフラグをサーバも受け入れる場合は同じようにフラグを送り返します。
すべての中間証明書ってどのくらいなの
Common CA Database によると、ルートと中間証明書の証明書は5415エントリとなっており、1つあたり数Kでもブラウザにバンドルするにも現実的な量な気がしました。