Re: 3.6.7 interoperability problems with earlier 3.6.x

Nikos Mavrogiannopoulos <[email protected]>
Newsgroups gmane.network.gnutls.general
Message-ID <CAJU7zaLqASUER5rwjLwy-HdY+1TLUGXhOVqd0SX43p8Pgu_CLw@mail.gmail.com>
On Mon, Jun 10, 2019 at 3:03 PM Andreas Metzler <[email protected]> wrote:
>
> On 2019-06-10 Nikos Mavrogiannopoulos <[email protected]> wrote:
> > On Sun, Jun 9, 2019 at 11:39 AM Andreas Metzler <[email protected]> wrote:
> [...]
>
> Hello Nikos,
>
> >> If you can think of specific changes in 3.6.8 that you think I should
> >> cherry-pick I would be very grateful. Perhaps #720 (IDNA)?
>
> > On the important bugs bucket I'd put the streebog fix, and the
> > gnutls_srp_set_server_credentials_function fix for 8192 parameters.
> > These two can cause serious issues to applications that use this
> > functionality but which were tested with the new release of gnutls,
> > but run on debian.
>
> That is c1441665abe761536b3ed67d36b12f2198be6b12 and
> 0bdca5d51f203cf414d645e75ac197e3fadfadc8.
>
> > The fix "Fixed bug preventing the use of gnutls_pubkey_verify_data2()
> > and gnutls_pubkey_verify_hash2() with the
> > GNUTLS_VERIFY_DISABLE_CA_SIGN flag (#754)", I think fits into the
> > previous bucket as well though its impact may be lower (fewer
> > applications using this flag).
>
> b1476abeb6f8b5046e6cd62724cdac241f71aa7b
>
> BTW: Afaict the respective test in the followup patch
> 1d3452d69670e28edfcaa232847036f600bbe1e8 is never run,
> tests/sign-verify-data-newapi.c tests/sign-verify-newapi.c does not seem
> to be referenced in any Makefile.

Thank you for that, a great catch. It seems that these tests were not
run other than on their addition and did not catch a regression they
intended to. I've proposed a fix for it:
https://gitlab.com/gnutls/gnutls/merge_requests/1025

> > The "During Diffie-Hellman operations in TLS, verify that the peer's
> > public key is on the right subgroup (y^q=1 mod p), when q is available
> > (under    TLS 1.3 and under earlier versions when RFC7919 parameters
> > are used)." is another security hardening measure that is due to NIST
> > requirements (there is no IETF guidance afaik) however it makes sense
> > IMHO.
>
> That would be 2555412f8982ec0a1bbbf6b3c10a0330fe848820 to
> e07061b29a75ff94f0dbf85ec44f7ad6c04761fa? i.e. this would include
> addition of gnutls_dh_params_import_raw3() and gnutls_ffdhe_????_group_q?

Yes. The new additions are mainly added to assist in testing. Maybe
too extensive to backport.

regards,
Nikos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.