TLS-RFC compliance about tlslite-ng

[tomato42]

Thanks for the report!
I'll go through them one by one later, two items caught my eye though:

when there are no overlapping parameters. tlslite-ng sends an 'illegal parameter' alert

Could you explain in what situation it happens? In majority of cases it should send the correct handshake_failure or insufficient_security.

upon receiving a ClientHello that contains elliptic curve extensions but no ECC cipher suite

I don't think enforcing that is useful; the extension may have been included because of an ECC ciphersuite that's unknown to the server, and even if all the ciphersuites are known, that's rather brittle code that does not increase interoperability or security.

[mmaehren]

Thank you for the feedback. We agree that enforcing this ECC cipher suite check may cause problems - that's a good point! I think the alert description for the lack of overlapping parameters may be caused by deprecated groups we include in the ClientHello we send in the test.

[tomato42]

I think the alert description for the lack of overlapping parameters may be caused by deprecated groups we include in the ClientHello we send in the test.

RFC 8446 says that deprecated groups "MUST NOT be offered or negotiated by TLS 1.3 implementations."; so that's what causing the rejection: if the ClientHello is recognised as a TLS 1.3 CH, and includes those obsolete curves then technically the message is malformed, so illegal_parameter is appropriate here. If you send them in TLS 1.2 you should see the expected handshake_failure, similar behaviour should be observed when using the unassigned curves (like from GREASE range).

[mmaehren]

Yes, it's a false positive on our end - sorry if my last comment didn't convey this.