On Tue, Jun 29, 2021 at 12:12:08PM +0200, Theo Buehler wrote:
+Cc jsing
The context is this: https://marc.info/?l=openbsd-bugs&m=162495046801363&w=2
On Tue, Jun 29, 2021 at 05:45:45AM -0400, Johnny Cast wrote:
On Tue, Jun 29, 2021 at 09:07:26AM +0200, Theo Buehler wrote:
> This is deliberate. The main reason is that P-521 is very expensive.
> This means that an attacker needs to feed you fewer key shares to keep a
> single server core busy than with the other curves, so it increases the
> risk of a DoS.
OK, that makes sense. My use case is IRC clients connecting to the rizon
network. Apparently many of their servers only support or allow P-521,
and you can't choose which one you connect to. I tried talking to
someone from their support channel and they were reluctant to even
discuss it with me at all. Maybe I'll try their forum, even though it
seems pretty inactive. Sounds like you have a good reason for leaving it
out of the defaults. Thanks again!
There is no risk client side. We could consider matching what libssl
does and allow P-521 for clients. This will need some plumbing as the
config setting is currently client/server agnostic.
In the interim, it should be easy enough for you to extend the config in
the irc client to allow P-521 like so:
if (tls_config_set_ecdhecurves(config, "X25519,P-256,P-384,P-512")) ==
-1)
errx(1, "tls_config_set_ecdhe_curves: %s",
tls_config_erorr(config));
If your client is catgirl, that would need to be done in irc.c. More
precisely, in ircConfig() after tls_config_new() and at the latest
before the call to tls_configure(client, config).
That sounds reasonable, I appreciate it. Catgirl is indeed the client
that brought this to my attention. A nice fellow from their mailing list
sent me a patch similar to what you described, which is how we confirmed
that P-521 was the issue.
