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

[Nikos Mavrogiannopoulos]

On Sun, Jun 9, 2019 at 11:39 AM Andreas Metzler <ametzler at bebt.de> wrote:
>
> On 2019-06-09 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> > On Sat, 2019-06-08 at 11:29 +0200, Andreas Metzler wrote:
> [...]
> > > I am now wondering on what to do with this bug for the next Debian
> > > stable release ("buster").
> > > * We are unlikely to upgrade to 3.6.8 since buster is already frozen.
>
> > What is blocking the upgrade to 3.6.8? Is there some further change to
> > do in the development rules so that debian can follow the stable
> > branch?
>
> Hello Nikos,
>
> the rules [1] for updates for the soon-to-be-released "buster" are very
> tight, every update is reviewed indiviually by an actual person.
> ---------------
> * targeted fixes for release critical bugs (i.e., bugs of severity
>   critical, grave, and serious) in all packages;
> * fixes for severity: important bugs in packages of priority: optional,
>   only when this can be done via unstable;
> * translation updates and documentation fixes that are included with
>   fixes for the above criteria;
> [...]
> A targeted fix is one with only the minimum necessary changes to resolve
> a bug.
> ---------------
>
> (An important bug is defined as "a bug which has a major effect on the
> usability of a package, without rendering it completely unusable to
> everyone.")
>
> A GnuTLS release on the stable branch OTOH can contain a lot more than
> that (essentially everything that does not break the API.)

I'd say break existing behavior (ABI or API). Thus the update may have
new stuff, but none of these can break existing applications.

> Looking at
> commits in 3.6.8 we find a lot of stuff that would not do for a Debian
> stable/frozen update.
> * beautification 8e28bb311ab33a1e7886e46af167311534070c39
> * New features (e.g AES-XTS)
> * cleanup (344c77b755f68370a098b90ef2ce981b829dd534 handshake: remove
>   unnecessary HSK_CRT_SENT flag)
> * Improvements for the test-suite
>
> I do not think that this is really solvable. GnuTLS and Debian release
> time are just not aligned and are not alignable. It is a matter of
> scale. - Debian cannot start doing bi-monthly stable releases including
> feature upgrades and GnuTLS would not improve if it switched to
> bi-annual releases (all new features happening in the unstable branch
> which was almost untested).

Ok.

> > Having multiple gnutls versions in the major distributions with
> > diverse behaviors would make things not easy in terms of
> > interoperability for tls1.3 or any other future feature.
>
> I think that is unavoidable.
>
> 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.

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

The "Apply STD3 ASCII rules in gnutls_idna_map() to prevent
hostname/domain crafting via IDNA conversion (#720)" is a security
hardening measure to prevent potential problematic hostnames. I'm not
aware of any exploitation under TLS/PKIX, though that doesn't mean
that it cannot.

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.

regards,
Nikos