[gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Tue Dec 10 15:09:54 CET 2024
Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 was reviewed by Alexander Sosedkin
--
Alexander Sosedkin commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250937010
> +}
> +
> +static inline bool group_is_supported(const gnutls_group_entry_st *group)
Discussed out-of-band, and woo, it's complicated. Turns out I was confusing `tls-enabled-group` with `enabled-curve`. We want orthogonality on the groups level, but that doesn't mean the curve primitive switch shouldn't disable the entire hybrid scheme. It can.
The good news are, looks like we can land it as is, with `enabled-curve` disabling a curve precluding the use of the affected hybrid group. This seems to be expected behaviour if `enabled-curve` is a primitive killswitch.
The bad news are, this still leaves at least one important use case uncovered, and that is a scenario when we consider a curve is broken, we need negotiating it as part of hybrid because that's widely deployed, but we don't want, say, trusting an intermediate ECC cert in the chain using that group.
Unfortunately, that'd require a separate RFE for a separate option or something. I've asked @tomato42 to file one.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20241210/6d762a90/attachment.html>
More information about the Gnutls-devel
mailing list