[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