[gnutls-devel] GnuTLS | GnuTLS continue in a conversation when second ClienHello is different than the first CH, in HRR. (#617)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Wed Nov 14 09:27:33 CET 2018
Thank you Robert for bringing that up. Is that the issue we discussed at: https://github.com/tomato42/tlsfuzzer/issues/398
If yes, I think my reply to that is still relevant, and I'm not sure we want to address it. Quoting below
> To add some context this test is about the https://tools.ietf.org/html/rfc8446#section-4.1.2 requirement:
```
The client will also send a
ClientHello when the server has responded to its ClientHello with a
HelloRetryRequest. In that case, the client MUST send the same
ClientHello without modification, except as follows:
- If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group.
- Removing the "early_data" extension (Section 4.2.10) if one was
present. Early data is not permitted after a HelloRetryRequest.
- Including a "cookie" extension if one was provided in the
HelloRetryRequest.
- Updating the "pre_shared_key" extension if present by recomputing
the "obfuscated_ticket_age" and binder values and (optionally)
removing any PSKs which are incompatible with the server's
indicated cipher suite.
- Optionally adding, removing, or changing the length of the
"padding" extension [RFC7685].
- Other modifications that may be allowed by an extension defined in
the future and present in the HelloRetryRequest.
```
> So that's a nice test to verify whether the server enforces that behavior (like tlslite-ng), but since the MUST is on the client to follow the rules, and not on the server to enforce, both behaviors look acceptable.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/617#note_117126565
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181114/d7aa3b0d/attachment.html>
More information about the Gnutls-devel
mailing list