2020/07/22 追記
HTTPでTLS ALPSを利用方法の仕様が別途提出されています。
「Using TLS Application-Layer Protocol Settings (ALPS) in HTTP」
GoogleのVictor Vasiliev氏から「TLS Application-Layer Protocol Settings Extension」という提案仕様が出ています。
これは、アプリケーションプロトコルで必要なパラメータをTLSハンドシェイク中に送信しちゃおうという提案仕様です。
例えば、HTTP/2やHTTP/3では、TLSハンドシェイク直後にSETTINGSパラメータを送り合い、お互いに受信できるヘッダ最大長やヘッダ圧縮に関するパラメータなどを相手に通知します。最初のHTTPリクエストをより早く送るために、相手からSETTINGSパラメータを受信する前にHTTPリクエストを送信は可能ですが、相手の上限値などを知らずに送信を開始する形になります。
このようなアプリケーションプロトコルで必要となるパラメータをTLSハンドシェイク中に相手に通知してしまおうという話です。(今回はHTTPの例を出しましたが、この拡張仕様はアプリケーションプロトコルを限定していません)
なお、送られるアプリケーションパラメータはEncryptedExtensionsで送られるため暗号化されます。
alps
この仕様では、application_settings (alps) TLS拡張を新しく定義しています。
流れとしては
- クライアントは、ClientHelloでalps拡張を送信します。これは単純に、この仕様に対応していることを示すために送られます。(alpnで送ったプロトコル識別子のうち、どれでサポートしてるかを示す)
- サーバは、この仕様に対応していればServerHelloで実際にアプリケーションパラメータを含むalps拡張を送信します。
- (クライアント認証を行う場合は、クライアントはアプリケーションパラメータを含むClientApplicationSettingsメッセージを送信できます)
補足
HTTPを含むアプリケーションプロトコルは、クライアントが先にアプリケーションデータを送信します。それまでに、サーバ側が設定したいパラメータがクライアントに届いてる必要があります。単純にこれを満たすためのであれば、既存のTLS1.3でも可能です。
サーバはFinishedを送ったあとに続けてアプリケーションデータを送信できるため、サーバからクライアントにアプリケーションパラメータを送信できます。
この点については、draft中に以下の通り書かれています
- 多くの実装は、クライアントからFinishedを受け取るまでアプリケーションデータの送信を待ちます
その他にも、0-RTTハンドシェイク時に以前のアプリケーションパラメータをTLSレイヤで保存しておけるといった利点があります。
なるほど。
