Index | Thread | Search

From:
Theo Buehler <tb@openbsd.org>
Subject:
Re: allow more sigalgs in client hello?
To:
Jonathan Matthew <jonathan@d14n.org>
Cc:
tech@openbsd.org, jsing@openbsd.org, beck@openbsd.org
Date:
Fri, 10 Jan 2025 12:54:02 +0100

Download raw body.

Thread
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...