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.