ExchangeAlgorithmType enum is missing 44550

[omghb]

Description

• ExchangeAlgorithmType enum is missing 44550
• I stumbled about this as I logged SslStream.KeyExchangeAlgorithm

Console.WriteLine("Key exchange: {0} strength {1}", stream.KeyExchangeAlgorithm, stream.KeyExchangeStrength);

https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream.keyexchangealgorithm?view=net-5.0

Configuration

.NET 5.0

Regression?

No, was never included.

Other information

See also Archived Forums > .NET Framework Class Libraries > SslStream.KeyExchangeAlgorithm 44550

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

• ExchangeAlgorithmType enum is missing 44550
• I stumbled about this as I logged SslStream.KeyExchangeAlgorithm

Console.WriteLine("Key exchange: {0} strength {1}", stream.KeyExchangeAlgorithm, stream.KeyExchangeStrength);

https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream.keyexchangealgorithm?view=net-5.0

Configuration

.NET 5.0

Regression?

No, was never included.

Other information

See also Archived Forums > .NET Framework Class Libraries > SslStream.KeyExchangeAlgorithm 44550

Author:	omghb
Assignees:	-
Labels:	area-System.Net.Security, untriaged
Milestone:	-

[karelz]

That would be missing in System.Security.Authentication.ExchangeAlgorithmType ... moving to Security area ...

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

• ExchangeAlgorithmType enum is missing 44550
• I stumbled about this as I logged SslStream.KeyExchangeAlgorithm

Console.WriteLine("Key exchange: {0} strength {1}", stream.KeyExchangeAlgorithm, stream.KeyExchangeStrength);

https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream.keyexchangealgorithm?view=net-5.0

Configuration

.NET 5.0

Regression?

No, was never included.

Other information

See also Archived Forums > .NET Framework Class Libraries > SslStream.KeyExchangeAlgorithm 44550

Author:	omghb
Assignees:	-
Labels:	area-System.Security, untriaged
Milestone:	-

[vcsjones]

I noticed that in the Unix PAL for KeyExchangeAlgorithm that DiffieHellman is used for ECDHE suites, whereas SChannel uses the unnamed enum value.

runtime/src/libraries/System.Net.Security/src/System/Net/Security/TlsCipherSuiteData.Lookup.cs

Lines 1833 to 1836 in b2a670b

	TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
	new TlsCipherSuiteData()
	{
	KeyExchangeAlgorithm = ExchangeAlgorithmType.DiffieHellman,

My understanding of ExchangeAlgorithmType.DiffieHellman is that it is for FF-DH, not ECDH. If a new enum value is added for ECDH then it would perhaps make sense to change the Unix PAL lookup to use the new enum instead of mixing it in with DiffieHellman.

[bartonjs]

@karelz The enum is part of System.Net.Primitives and is logically part of SslStream, namespace notwithstanding.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

• ExchangeAlgorithmType enum is missing 44550
• I stumbled about this as I logged SslStream.KeyExchangeAlgorithm

Console.WriteLine("Key exchange: {0} strength {1}", stream.KeyExchangeAlgorithm, stream.KeyExchangeStrength);

https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream.keyexchangealgorithm?view=net-5.0

Configuration

.NET 5.0

Regression?

No, was never included.

Other information

See also Archived Forums > .NET Framework Class Libraries > SslStream.KeyExchangeAlgorithm 44550

Author:	omghb
Assignees:	-
Labels:	area-System.Net.Security, untriaged
Milestone:	-

[rzikm]

Looks like we explicitly group all Diffie-Hellman variants together to a single enum value (https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/src/System/Net/Security/TlsCipherSuiteNameParser.ttinclude#L75-L96), we can do the same on Windows for consistency, or add new enum values and use them everywhere.

[bartonjs]

I think a distinct value is better. Presumably SChannel agreed, as presumably 44550 is a number out of Windows SslStream.

If non-Windows is folding it down to FF-DH that's just because of a square-peg/round-hole (but-I-have-a-lathe!) problem.

[wfurt]

triage: we should add new enum and fix up the mapping.

[rzikm]

Triage: It would be good to update all 3 enum types pertaining to the cipher suite properties to stay current and to report more detailed information for users who use the properties for auditing purposes.

[rzikm]

I tried looking into adding more values so that we are on par with what we get from TLS ciphersuites in

runtime/src/libraries/System.Net.Security/src/System/Net/Security/TlsCipherSuiteNameParser.ttinclude

Lines 11 to 71 in f92b9ef

	public enum ExchangeAlgorithmType
	{
	None,
	Rsa,
	DiffieHellmanStatic,
	DiffieHellmanEphermal,
	ECDiffieHellman,
	ECDiffieHellmanEphermal,
	Kerberos5,
	PSK,
	SRP,
	ECCPWD,
	Any,
	}
	public enum CipherAlgorithmType
	{
	Aes,
	Aes128,
	Aes192,
	Aes256,
	Des,
	None,
	Null,
	Rc2,
	Rc4,
	TripleDes,
	AesGcm,
	AesCcm,
	Aes128Gcm,
	Aes256Gcm,
	Aes128Ccm,
	Aes128Ccm8,
	Aes256Ccm,
	Aes256Ccm8,
	Camellia,
	Camellia128,
	Camellia256,
	Camellia128Gcm,
	Camellia256Gcm,
	ChaCha20,
	ChaCha20Poly1305,
	Seed,
	Idea,
	Aria,
	Aria128,
	Aria256,
	Aria128Gcm,
	Aria256Gcm,
	}
	public enum HashAlgorithmType
	{
	None,
	Md5,
	Sha1,
	Sha256,
	Sha384,
	Sha512,
	Aead,
	}

So far, there are following obstacles:

• The numerical values of the enums seem to be the wincrypt.h algorithm identifier, but some algorithms are not supported by wincrypt and don't have such an identifier assigned, e.g. Kerberos5, ECCPWD, Camellia, ChaCha20, Aria*
• related to the above, wincrypt alg ids don't seem to distinguish between GCM or CCM or CCM_8 modes of AES ciphers

@wfurt, @bartonjs do we care about using the same numbers as underlying windows crypto does? I think we could do without it and just use the lookup table we have for Unix on all OSes and gain also consistency.

[bartonjs]

do we care about using the same numbers as underlying windows crypto does?

My gut says the numbers are the same so that no one had to write a mapping table; a convenience that only made sense when the framework was (largely) Windows-only. So, "no" (but we can't change any of the existing numbered things).

[wfurt]

We had similar problem with https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.protocolfamily?view=net-8.0 There are some Linux specific so we put them to the end so they are less likely to collide with Windows numbering.
If Windows will ever supports them we will need to add some mapping like we do for other platforms.

[rzikm]

Moving to 10.0.0 milestone as this is not critical to 9.0.0, but still would be nice to get it in.

[rzikm]

Since #100361, the plan is to obsolete the enum, closing as won't do.