あどけない話

Internet technologies

TLS 1.3 開発日記 その30 NewSessionTicket 再考

NewSessionTicketをいつ送るかの議論です。

まず、TLS 1.3 開発日記 その9 NewSessionTicketをお読み下さい。

Haskell TLS の実装では、Client Finished の値を予測して NewSessionTicket を作成し、handshake() API が送信していました。このときは、クライアント認証は実装していませんでした。

クライアント認証を実装するにあたり、Haskell TLS ライブラリのメンテナの間で、この方法は適切なのか議論になりました。サーバはクライアント認証を要求している場合でも、クライアントを認証する前に NewSessionTicket を送るからです。サーバがクライアント認証に失敗し、クライアントの接続を拒否したとします。しかし、クライアントはチケットを手に入れているので、再び接続すればクライアント認証を省略してハンドシェイクを完了できます。

いくつかの意見が出されたのですが、結局 Client Finished の到着後、つまり必要であればクラアント認証を完了してから、recvAppData() API が NewSessionTicket を送ることになりました。