Extend TLS information available in HandshakeData

[ollbx]

Quinn currently seems to provide no way to access information about the TLS encryption, such as the cipher suite or the protocol version. I think it would make sense to expose this information via API. Therefore this pull request extends the HandshakeData available via Connection::handshake_data() + downcast with some additional information.

Design considerations:

• The negotiated_key_exchange_group field already existed, guarded by the internal feature flag __rustls-post-quantum-test for CI / testing. I kept the name, but changed its type to be an Option, since the rustls documentation states that this can be None in some cases (TLSv1.2 with resume for example). I also changed the unit test accordingly.
• As before negotiated_key_exchange_group just returns the NamedGroup. I think this is likely sufficient and has the advantage of only exposing one additional enum type in the API.
• For negotiated_cipher_suite I did something similar and only return the value of the CipherSuite enum. I'm not sure if the other information in SupportedCipherSuite is really that relevant.
• The documentation for the new fields is mostly copied from rustls documentation.

[Ralith]

Can you elaborate on the use case? Some of these fields don't make sense for QUIC -- the TLS version is always 1.3, for example.

[ollbx]

Right now, I'm admittedly mostly using this for my own debugging, so I don't have a concrete use-case. But I think it would be useful in general to have the information available and make it possible to show this to advanced end-users.

Let's say I build a program based on quinn and there is a new vulnerability in some cipher suite. The hotfix recommendation is to switch to an alternative cipher. Then I as a user of that program (or as its developer) would like to be able to confirm that after updating the program or changing the configuration, the compromised cipher is actually no longer being used.

Another reason is that given it is a negotiation, the cipher is actually dependent on both sides. So I may want to check which cipher is used when communicating with other QUIC implementations or maybe check what is being negotiated between different versions. I'm sure there are other cases where this would be useful (the existing code for the unit test seems to indicate the need already came up before 😉).

The TLS version always being 1.3 is a fair point. But I suppose at some point in the future this could also become 1.4?

[Ralith]

[confirm a] compromised cipher is actually no longer being used.

I don't think omitting a suite from the rustls CryptoProvider leaves much room for ambiguity -- negotiation can never select a suite you don't advertise. Overall, I tend to think exploratory diagnostics are better served by logging, which doesn't prevent as great a compatibility or maintenance hazard.

But I suppose at some point in the future this could also become 1.4?

That point in the future would be when we might consider adding fields which only make sense in that case, and regardless we don't need to make allowances for TLS <=1.2.

[djc]

Yeah, not really inclined to add a bunch of stuff if you don't have an actual use case.