0)が正解じゃないかと思います。これ間違うと鍵交換後にエラーって、めちゃハマります(体験談)。server_handshake_traffic_secret.全てのハンドシェイクでは、サーバはSeverHelloメッセージの直後にEncryptedExtensionsを送らなければならない(MUST)。server_handshake-traffic_secretから生成した鍵で暗号化される最初のメッセージである。Optionalが付いてなかったのを見落としちゃったのかもしれません。見たら左側TLS1.2の図もおかしいです。Finishedも赤字にするのが正確でしょう。253bitが適応外になる!)今回一番声を大にして言いたいのはここです。高セキュリティ型、推奨セキュリティ型、セキュリティ例外型の全て要求仕様において、以下の通り「鍵長256ビット以上のECDHE」が求められています。P-256(secp256r1)の導入を前提としているかと思われます。2017で私がプレゼンした「運用の観点から見たTLSプロトコルの動き」の資料とくらべてみましょう。ガイドラインで要求仕様に入っているDHEは、私の資料では黄色(注意)にしています(理由は後述)。青色の部分はガイドラインに入っていません。CRYPTRECはNISTと異なり推奨楕円曲線を規定していません。curveに限ると明確に書いていません)。256bit以上という条件では、253bitのX25519が適応外になってしまいます。253bits)も認めないのかぁ。こりゃOpenSSL-1.1.x系をそのまま導入するとガイドライン違反になっちゃうよ。2018年5月8日とつぶやいちゃいました。換算が曖昧なセキュリティレベルでの規定(128bit相当)ならいざしらず、ちゃんと計算できる鍵長で、たかが3bitだからといい加減にできないのではないかと思います。RFC7540-HTTP/2仕様では、「利用するEC鍵長は224bits以上でなければならない」と規定しました。これは当時仕様策定中のX25519が使えることを考慮して決めた値です。DTLSでも192bits以下は使うべきではないとの規定です。ガイドラインが求める鍵長256bit以上ではX25519を使えず、同程度のセキュリティレベルのRSA2048やDHE2048が使えるのに比べて、少し厳しいのではないかというのが自分の意見です。これからの事を考えるとやっぱりアカンと思い、X25519がどういう経緯で作られ、現在どうなっているのか、少し解説したいと思います。(書いてみたら膨大になってしまったので最後の節に回します。