2020/02/23 追記
下記提案はRFC8740として標準化されました
https://tools.ietf.org/html/rfc8740
GoogleのDavid Benjamin氏より「Using TLS 1.3 with HTTP/2」という提案仕様が出されています。
この仕様自体は、単純にHTTP/2においてTLS1.3のpost-handshake authenticationを禁止するものです。
HTTP/2でTLS1.2を使用している場合はrenegotiatoinが禁止されており、同様の課題をもつTLS1.3のpost-handshake authenticationも明示的に禁止するというのがこの提案です。
背景
Webサービスを利用している際、特定のURL(管理用ページなど)だけセキュリティーレベルが高く、クライアント証明書を用いた認証を行いたい場合があります。
一般的にTLS1.2ではコネクションを確立したあとにクライアント証明書を要求する場合はrenegotiationという手順をとっていました。
しかし、HTTP/2では一つのコネクション上でHTTPリクエストが並列的に送信されます。このTLS1.2のrenegotiationでは、どのHTTPリクエストによってrenegotiationがトリガされたかクライアントは分からないという課題がありました。
(TLS1.2のrenegotiationが脆弱だという話もありつつ。)
TLS1.3では、post-handshake authenticationという形でコネクションを確立したあとにクライアント証明書の要求/送信が行えるようになりました。
しかしHTTP/2を利用しているとき、多重化されたHTTPリクエストのどれがpost-handshake authenticationのトリガになったかという課題は同じです。ですので、改めてHTTP/2でTLS1.3を利用している場合、post-handshake authenticationの禁止を明示します。
Secondary Certificate Authentication in HTTP/2
それでは、追加でクライアント証明書を要求する場合どうするのかというと、別の提案仕様が提出されています。
詳細は以前書いたとおりです。
asnokaze.hatenablog.com
この仕様では、どのストリームが証明書を要求しているかを関連付けることが出来、HTTP/2レイヤで証明書の要求及び送信を行うことで先の課題を解決しています。
もともとはこちらの提案仕様が先に出されていたわけですが、議論の結果、post-handshake authenticationの禁止は別提案として明文化するようになりました。
その話が書かれたメールは下記です
lists.w3.org
