[gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x

[Nikos Mavrogiannopoulos]

On Mon, Jun 10, 2019 at 3:03 PM Andreas Metzler <ametzler at bebt.de> wrote:
>
> On 2019-06-10 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > On Sun, Jun 9, 2019 at 11:39 AM Andreas Metzler <ametzler at bebt.de> 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