[API Proposal]: Expose TLS details for QUIC connection #70184
Description
Background and motivation
ASP.NET Core has an ITlsHandshakeFeature type that a dev can use to get information about the TLS connection. We want to support it for HTTP/3: today HTTP/3 only runs on TLS 1.3, but it'll eventually also run on whatever comes after TLS 1.3 and there needs to be a way for people to get that information.
We (asp.net core team) think that this has been discussed and brought up before but I couldn't find an issue in runtime for exposing this information. Tracking in asp.net core: dotnet/aspnetcore#35039. This doesn't block HTTP/3 for us in .NET 7 but will eventually need to be done.
API Proposal (edited by @rzikm)
The proposed API adds following two properties.
public class QuicConnection
{
//
// Version of TLS used for the handshake, currently expected to always return Tls13
//
public SslProtocols SslProtocol { get; }
//
// currently, QUIC allows negotiating only following TLS 1.3 ciphers
// - TLS_AES_128_GCM_SHA256 = 0x1301, // rfc8446
// - TLS_AES_256_GCM_SHA384 = 0x1302, // rfc8446
// - TLS_CHACHA20_POLY1305_SHA256 = 0x1303, // rfc8446
// - TLS_AES_128_CCM_SHA256 = 0x1304, // rfc8446
//
[CLSCompliant(false)]
public TlsCipherSuite NegotiatedCipherSuite { get; }
}These properties contain all the relevant information.
API Usage
await using var connection = await listener.AcceptConnectionAsync();
Console.WriteLine($"connection.NegotiatedCipherSuite: {connection.NegotiatedCipherSuite}");
Console.WriteLine($"connection.SslProtocol: {connection.SslProtocol}");Potential output:
connection.NegotiatedCipherSuite: TLS_AES_256_GCM_SHA384
connection.SslProtocol: Tls13
Alternative Designs
Put all the properties on a new class QuicConnectionInfo instead of directly on QuicConnection. This would be consistent with SslStream, but would impose an extra allocation (unless we make the new type struct). Furthermore, we already have NegotiatedApplicationProtocol on QuicConnection so it seems preferrable to have all properties directly on QuicConnection.
Decomposition of TlsCipherSuite into individual values as in SslStream
Not applicable anymore, releavant types obsoleted as of #100361
SslStream contains also additional properties which expose additional metadata about the cipher suite, however, not all of these properties make sense for QUIC, see comments inline.
public class QuicConnection
{
// covered in the proposal at the top
public SslProtocols SslProtocol { get; }
public TlsCipherSuite NegotiatedCipherSuite { get; }
// based on the above, currently expected to return
// - Aes128
// - Aes256
// - None (for ChaCha20Poly1305) = based on SslConnectionInfo.Unix.cs, we probably don't have appropriate member for that. We can enhance CipherAlgorithmType enum in another proposal.
+ public CipherAlgorithmType CipherAlgorithm { get; }
// based on the above, expected to return
// - 128 (Aes128)
// - 256 (Aes256 and ChaCha20Poly1305)
+ public int CipherStrength { get; }
//
// defined in SslStream but don't make that much sense as QUIC does not use the HashAlgorithm during encryption (it uses AEAD of version of the CipherAlgorithm which don't use the hash algorithm
// from the cipher suite), and it would only be reported because it was part of the negotiated cipher suite
//
+ public HashAlgorithmType HashAlgorithm { get; }
// MsQuic currently returns always 0 for all ciphers, and same behavior is on SslStream as well on the cipers above (based on SslConnectionInfo.Unix.cs)
+ public int HashStrength { get; }
//
// based on SslConnectionInfo.Unix.cs these would return 0/None in all cases
//
+ public ExchangeAlgorithmType KeyExchangeAlgorithm { get; }
+ public int KeyExchangeStrength { get; }
}Risks
Possible small risk if some future version of QUIC uses different security protocol for handshake other than TLS (and we cant fit the value into SslProtocols enum)