[Feature]: hello retry request support

[ruiqizhou]

Before request a new feature

• I have searched the issues of this repository and believe that this is not a duplicate.

Describe the feature you'd like supported

https://datatracker.ietf.org/doc/html/rfc9001#section-4.7

The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be used to request that a client provide new information, such as a key share, or to validate some characteristic of the client. From the perspective of QUIC, HelloRetryRequest is not differentiated from other cryptographic handshake messages that are carried in Initial packets. Although it is in principle possible to use this feature for address verification, QUIC implementations SHOULD instead use the Retry feature; see Section 8.1 of [QUIC-TRANSPORT].

Describe alternatives you've considered

No response

Additional context

No response

[richardoLee]

Hi there! Is it possible to assign this issue to me? I am a newcomer and want to give it a try, although it might spend some time.

[ruiqizhou]

Hi there! Is it possible to assign this issue to me? I am a newcomer and want to give it a try, although it might spend some time.

OK

[ruiqizhou]

@richardoLee Hi, are you still working on this feature?

[richardoLee]

@richardoLee Hi, are you still working on this feature?

Yeah. I'm currently trying to locate where the ServerHello and HelloRetryRequest messages are.

[ruiqizhou]

@richardoLee Hi, are you still working on this feature?

Yeah. I'm currently trying to locate where the ServerHello and HelloRetryRequest messages are.

Great! Feel free to contact me if you have any questions. 🙌

[richardoLee]

Great! Feel free to contact me if you have any questions. raised_hands

When using Wireshark to catch QUIC packets, I found these packets were encrypted (of course). I tried several ways to handle but none of them worked. Is there any suggestion?

[ruiqizhou]

Great! Feel free to contact me if you have any questions. raised_hands

When using Wireshark to catch QUIC packets, I found these packets were encrypted (of course). I tried several ways to handle but none of them worked. Is there any suggestion?

1. check WireShark version.
2. use cmake -DXQC_PRINT_SECRET=1 .. to print QUIC/TLS 1.3 traffic secrets following the SSLKEYLOGFILE key log file format.
3. The keylog file will be saved as ./ckeys.log or ./skeys.log if you run test_server & test_client.
4. Wireshark -> (Pre)-Master-Secret log

A document detailing how to use Wireshark decrypting QUIC packets will be uploaded shortly.

[richardoLee]

Hi! Sorry to bother. I encountered a function int xqc_tls_add_handshake_data(SSL *ssl, enum ssl_encryption_level_t level, const uint8_t *data, size_t len) when tracking crypto frames. But none of any definition of ssl_encryption_level_t was found. I am wondering what this enumeration means and where I can find it?

[Moxoo]

Hi! Sorry to bother. I encountered a function int xqc_tls_add_handshake_data(SSL *ssl, enum ssl_encryption_level_t level, const uint8_t *data, size_t len) when tracking crypto frames. But none of any definition of ssl_encryption_level_t was found. I am wondering what this enumeration means and where I can find it?

In line 3281 of third_party/boringssl/include/openssl/ssl.h, hope it's useful for you.

[Moxoo]

@richardoLee Hi, are you still working on this feature?

Yeah. I'm currently trying to locate where the ServerHello and HelloRetryRequest messages are.

Great! Feel free to contact me if you have any questions. 🙌

I found the default order of support_group((EC)DHE groups) in boringssl is "X25519, 256R1, 384R1", while the default order of this in xquic.h is "P-256, X25519, P-384...". So, when I test the xquic test_client with boringssl-based QuicServer (e.g. quiche server), a HelloRetryRequest message appeared. However, xquic test_client doesn't seem to support "retry", I guess？ I'm really really really looking forward to this great ‘retry’ feature, although I can successfully interoperate with quiche by modifying XQUIC's default order to 'X25519, P-256, P-384...'.

[richardoLee]

@Moxoo What does retry feature mean? RFC 9001 also mentioned this:

Although it is in principle possible to use this feature for address verification, QUIC implementations SHOULD instead use the Retry feature.

[richardoLee]

@ruiqizhou Hi! I noticed that HelloRetryRequest message appeares when TLS handshakes and xquic now just sent this Key Exchange Messages without reading and processing it. So what is this feature supposed to do when a client encounter a HelloRetryRequest? Client should read the crypto frame and then resend ClientHello?