TLS暗号スイートのペアリングの目的は何ですか？彼らはなぜ彼らがそうであるようにペアリングされたのですか？
あらかじめ定義された暗号スイートのセットがあるのはなぜですか。独自の暗号スイートを作成することが推奨されないのはなぜですか。
SSLv3からTLS 1.2までのTLS 1.3以前のバージョンについて質問しているかどうか、質問の正確な意味について少し詳しい情報が必要です。現在不可能です。
すでにTLSに指定されているプリミティブのみを使用するつもりで、SSHのようにそれらをより自由に混合して一致させたい場合は、（ [〜＃〜] kex [〜＃〜][〜＃〜] auth [〜＃〜][〜＃〜] ciphers [〜＃〜][〜＃〜] mac [〜＃〜] ）、TLSを使用できない理由の答えはおそらく部分的には歴史的であり、部分的にはオプションの数が少ないほど、複雑さが少なく、許可されたオプションの検査が多いためです。
オプションをできるだけ少なくする方が安全です。現代の考え方は、暗号アルゴリズムの俊敏性（1990年代のアイデア） 間違いでした であり、現代の設計では、交渉は問題を引き起こすだけであり、正しいことは、ネゴシエートされた値（プロトコルバージョン）および単一の許可された値の長期のみをサポートする（クライアントとサーバーの同期を外すために、2つの可能な値の短期をサポートする必要がある場合があります）。したがって、たとえば WireGuard を使用すると、X25519 + ChaCha20Poly1305 + Blake2sになります。プリミティブのいずれかが壊れていることが判明した場合、または建具が壊れていることが判明した場合、またははるかに速いものが発明された場合、または人々が非常に異なるハードウェア用に最適化されたものに切り替えることを決定した場合、新しいプロトコルは新しいプロトコル識別子とユーザーが切り替わり、下位互換性を長期間維持することは推奨されません。
したがって、たとえば、TLS1.2でDHE 2048 + ECDSA P-256 + AES-128-GCM + SHA256を実行する場合、そのような暗号スイートはないため、実行できません。かなり標準的なクライアントとサーバーですがコードはこれを簡単にサポートでき（IMO）、安全に実行できます（IMO）。これは、ほとんど購入しないと思う制限です（テストセットの組み合わせを改善します）。
独自のプリミティブを使用したい場合はどうなりますか？たとえば、Curve25519またはNIST P-256の代わりに Curve9767 を使用するECDH？または、AESGCMやChaPolyの代わりに Gimli または Xoodoo （ also ）に基づく対称暗号を使用する場合はどうなりますか？まあ、あなたが使用できる割り当てられていない暗号スイートIDがあります。クライアントが暗号スイートを提供する場合は暗号スイートを選択するサーバーを実装し、サーバーが選択した場合は暗号スイートを提供して使用するクライアントを実装し、サポートするクライアントとサーバーの間で接続が確立されると新しい暗号を使用できます。スイートが使用されます。これが Google 、 Cloudflare および [〜＃〜] aws [〜＃〜] が量子暗号化実験を行い、一部の人々がどのように使用したか国家バニティ暗号（ ???????????????? ）。
PRFを変更したいので、クライアントにSHA2実装が必要ない場合はどうなりますか（署名でBlake3をMACなどとして使用するとします）。暗号スイートはそれを行うことができます（IIRC）。
建具を変更したい場合、プリミティブを組み合わせる方法はどうでしょうか？
たとえば、非対称署名を使用する代わりに、非対称認証に Noise のようにECDH + HMACを使用します。これは、フローを変更するSignatureAndHashAlgorithmの新しい値である可能性があります（クライアントによって提供され、サーバーによって選択された場合）。または拡張機能かもしれません。よく分かりません。
基本的には、ClientHelloメッセージはRFCが言うように見えますが、未知の暗号スイートが許可され、新しい拡張が許可され、拡張がプロトコルを完全に変更できるという考え方です。対応するミドルボックスは、ServerHello、Certificate、およびServeKeyExchangeメッセージが存在することを想定していても意味がないはずです。ClientHelloの拡張機能は、それをサポートするサーバーに「完全に異なるプロトコルに切り替えましょう」という意味になる可能性があるためです。残念ながら、実際には、ミドルボックスはすべての人の存在の悩みの種であり、TLS1.3は機能的に奇妙なことを行う必要があり、拡張機能を使用したTLS1.2フローの大幅な変更は、企業のミドルボックスの背後のクライアントではおそらく機能しません。ただし、内部ネットワークでは問題ありません。 TLS1.3は、ハンドシェイクの多くを暗号化して、ミドルボックスから（そしてプライバシーのために）何を行うかを隠し、拡張を容易にします。
非対称認証にX.509証明書以外のものを使用したい場合はどうなりますか？ TLS仕様では、X.509を使用する必要があると記載されています。プロトコルを十分に変更したら、作成した「TLS」の呼び出しを停止するときがきました。これはGoogleが 内部で使用するもの で行ったことです。