QUIC transport parameters extension

[botovq]

Bug Report

System Information

Type	Version/Name
Operating System Name	OpenBSD
Operating System Version	7.1-current
Python version	3.9.13
tlslite-ng version	0.8.0-alpha43
tlsfuzzer revision	c56a143

Problem description

tlsfuzzer sends the QUIC transport parameters extension (extension number 57) in various test scripts, for example in test-tls13-shuffled-extentions.py, test-tls13-large-number-of-extensions.py, or test-large-hello.py. This extension MUST NOT be sent unless the transport is QUIC and endpoints that support the extension receiving it MUST abort the handshake with an unsupported extension alert, see the penultimate paragraph in RFC 9001, section 8.2.

While it is possible to work around this by excluding extension number 57 using the --exc command line flag or using -m in the case of test-large-hello.py, it would be nice if tlsfuzzer did not send this extension by default, or, alternatively, if it didn't fail on receiving an unsupported extension alert on sending it.

Describe how to reproduce the problem

We ran into this issue during our regular tlsfuzzer runs against LibreSSL head with this commit:
openbsd/src@db80cf4

Expected behaviour

tlsfuzzer does not send QUIC transport parameters or if it does it handles unsupported extension alerts gracefully.

Include errors or backtraces

multiple extensions 16377 ...
Error encountered while processing node ExpectServerHello() (child: <tlsfuzzer.expect.ExpectCertificate object at 0x4acdd4f5280>) with last message being: <tlslite.messages.Message object at 0x4ad338f47f0>
Error while processing
Traceback (most recent call last):
  File "/usr/local/share/tlsfuzzer/scripts/test-large-hello.py", line 423, in main
    runner.run()
  File "/usr/local/lib/python3.9/site-packages/tlsfuzzer/runner.py", line 234, in run
    raise AssertionError("Unexpected message from peer: " +
AssertionError: Unexpected message from peer: Alert(fatal, unsupported_extension)

[tomato42]

yes, the scripts should be modified to not send them

they intentionally send low numbered extensions to break when an implementation includes new features, thus we need more tests...