From: Theo Buehler Subject: Re: allow more sigalgs in client hello? To: Jonathan Matthew Cc: tech@openbsd.org, jsing@openbsd.org, beck@openbsd.org Date: Fri, 10 Jan 2025 12:54:02 +0100 On Fri, Jan 10, 2025 at 09:46:45PM +1000, Jonathan Matthew wrote: > 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. > Which is part of the first column in table below: > > > > https://github.com/open-quantum-safe/oqs-provider/blob/35529a04b0530817c59dcf06df97493574428bd3/oqsprov/oqsprov_capabilities.c#L240-L269 > > > 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. Let's hope so...