From: Jonathan Matthew Subject: Re: allow more sigalgs in client hello? To: Theo Buehler Cc: tech@openbsd.org, jsing@openbsd.org, beck@openbsd.org Date: Fri, 10 Jan 2025 21:46:45 +1000 On Wed, Jan 08, 2025 at 12:01:59AM +0100, Theo Buehler wrote: > 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"? Something along the lines of 'Unknown (0xfeXX)', which is what prompted me to look in this direction. > > 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. Fair enough. It's not a problem for me now that I know about it. I suspect the number of other people likely to run into this is pretty low.