On Tue, Jan 07, 2025 at 11:18:00AM +1000, Jonathan Matthew wrote:
> OmniOS now ships and enables oqsprovider (quantum-safe crypto
> provider for openssl) by default.

Enabling the oqs provider to play with PQ stuff is one thing. Enabling
all this (non-standard as far as TLS is concerned) stuff and expecting
it to interoperate is another. Most of this should still be considered
experimental at best.

The only thing that is reasonably close to being standardized on ietf-tls
is ML-KEM combined with various curves. Reasonable people still disagree
if adding any PQ signature scheme at all to TLS is a good idea.

> One thing this does is add lots of sigalgs to the TLS client hello.
> Wireshark says there are 71 of them in there.

No PQ signature algorithms have code points for use in TLS assigned
in IANA's signature schemes list. I guess that wireshark shows these
"ad-hoc assignments"?

https://github.com/open-quantum-safe/oqs-provider/blob/35529a04b0530817c59dcf06df97493574428bd3/oqsprov/oqsprov_capabilities.c#L240-L269

Compare with the official registry:

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme

There are currently 37 code points assigned and fewer than 20 recommended.
Dumping twice as many as assigned and four times as many as recommended
on everyone else who hasn't joined in on the PQ joyride is just bad form,
to put it mildly.

> Trying to connect to a server that uses LibreSSL
> fails like this:
> 
> $ curl -vi https://openbsd.org/
>  
> [...]
> 
> * ALPN: curl offers h2,http/1.1
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> *  CAfile: /etc/ssl/cacert.pem
> *  CApath: /etc/ssl/certs
> * TLSv1.3 (IN), TLS alert, decode error (562):
> * OpenSSL/3.3.2: error:0A00041A:SSL routines::tlsv1 alert decode error
> 
> because LibreSSL will reject anything with a sigalg extension longer
> than 64 bytes.  Increasing this to 256 bytes, as in the diff below,
> allows OmniOS clients to connect.  Is this a reasonable thing to do?

Not really. This feels like heading right back to the glory days of
cargo culted TLS cipher strings harvested from various forum.php.

All that said, I'm not strongly opposed to raising the limit if this is
a significant point of friction. But the stringent limit isn't my idea,
so jsing and beck might have stronger opinions.

> 
> 
> Index: ssl_tlsext.c
> ===================================================================
> RCS file: /cvs/src/lib/libssl/ssl_tlsext.c,v
> diff -u -p -u -p -r1.154 ssl_tlsext.c
> --- ssl_tlsext.c	9 Jul 2024 12:27:27 -0000	1.154
> +++ ssl_tlsext.c	7 Jan 2025 00:14:00 -0000
> @@ -600,7 +600,7 @@ tlsext_sigalgs_server_process(SSL *s, ui
>  
>  	if (!CBS_get_u16_length_prefixed(cbs, &sigalgs))
>  		return 0;
> -	if (CBS_len(&sigalgs) % 2 != 0 || CBS_len(&sigalgs) > 64)
> +	if (CBS_len(&sigalgs) % 2 != 0 || CBS_len(&sigalgs) > 256)
>  		return 0;
>  	if (!CBS_stow(&sigalgs, &s->s3->hs.sigalgs, &s->s3->hs.sigalgs_len))
>  		return 0;