TLSにおけるTicketRequest拡張の提案仕様 (RFC 9149)

(追記) 2022年、RFC 9149として標準化されました

==
Appleの人らによって「TLS Ticket Requests」という、TLSでのセッション再開に利用するチケットに関する拡張仕様が提案されています。

TLSはあまり詳しくないのですが簡単に読む

TLS session ticket

まず、TLS session ticketとセッション再開について確認する


TLSでは一度ハンドシェイクを行った相手と、セッションを再開するための手順が用意されています。これにより処理量を少なくできます。

セッション情報を暗号化しTicketとしてクライアントに渡すことで、サーバ側はセッション再開のために情報を保持しておく必要がなくなります。

Ticketに関する拡張仕様は、RFC5077「TLS Session Resumption without Server-Side State」で標準化されていますし、TLS1.3の仕様でもTicketに関する定義がされています。

  • TLS1.3の仕様では、最初のハンドシェイクの際にクライアントがFinishedを送った後に、サーバからNewSessionTicketメッセージでticketをクライアントに発行します。

  • 以降セッションを再開する場合は、pre_shared_key拡張を付与してセッションの再開を行います。セッションの再開ですので、サーバから「Certificate」「CertificateVerify」は送信されません。


TicketRequest概要

現在の仕様でも複数のticketを発行できますが、その発行する数はサーバが決めています。


Appleの人らが提案している「TLS Ticket Requests」では、クライアント側からticketを要求できるようになっています。これによって、クライアント側から必要なだけticketをサーバに要求できます。


例えばHTTPSなどの通信では、同じサーバに対して複数のコネクションをはる場合もあります。それはクライアントが並列数を選ぶので、欲しいticketの数をクライアントが決めるのは合理的です。


同じticketは1回のみ使用されるべきですので、クライアント側から要求すればticketが少なすぎることもなくなりますし、逆にサーバ側から過剰にticketを発行することも防げます。

TicketRequest拡張

ハンドシェイク時にticket_request(TBD)拡張を送ることで、TicketRequestに対応しているかネゴシエーションを行います。

お互いに対応していれば、ハンドシェイク後にTicketRequestメッセージを送ることでticketを要求できます。

   struct {
       opaque identifier<0..255>;
       opaque context<0..2^16-1>;
   } TicketRequest;