Re: [gnutls-devel] GnuTLS | Soft-disabling configuration capabilities should match the hard-disabling ones (#1172)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [gnutls-devel] GnuTLS | Soft-disabling configuration capabilities should match the hard-disabling ones (#1172)

Read-only notification of GnuTLS library development activities
GitLab

Daiki Ueno commented:

This is probably a stupid idea, but I was thinking to allow multiple named [overrides] sections, e.g., [overrides.EXAMPLE]. The name (EXAMPLE) can be referred to in the [priorities] section. That way, we can overcome the limitation of priority strings and also define soft-disablement in a declarative manner in a single place.

For example:

[overrides.EXAMPLE1]
insecure-sig = rsa-sha1

[overrides.EXAMPLE2]
insecure-sig = rsa-sha256

[priorities]
EXAMPLE1 = EXAMPLE1
EXAMPLE2 = EXAMPLE2
SYSTEM = NORMAL

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gnutls-devel] GnuTLS | Soft-disabling configuration capabilities should match the hard-disabling ones (#1172)

Read-only notification of GnuTLS library development activities
GitLab

Milestone changed to Release of GnuTLS 3.7.2 release


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gnutls-devel] GnuTLS | Soft-disabling configuration capabilities should match the hard-disabling ones (#1172)

Read-only notification of GnuTLS library development activities
In reply to this post by Read-only notification of GnuTLS library development activities
GitLab

Alexander Sosedkin commented:

So, the effective configuration now, with a config specifying "hard-disabled" and "config-priority" is:

  • for non-TLS: "everything - hard-disabled",
  • for TLS not using @SYSTEM: "priority",
  • for TLS using @SYSTEM:extra-priority: "config-priority +- extra-priority - hard-disabled".

And what we're aiming for given a config that specifies "soft-disabled", "hard-disabled" and "config-priority":

  • for non-TLS: "everything - soft-disabled +- new-api - hard-disabled",
  • for TLS not using @system: "priority +- new-api",
  • for TLS using @system:extra-priority: "config-priority - soft-disabled +- extra-priority +- new-api - hard-disabled".

(italics signify what's under the application control)

Questions:

  • did I get your proposal right?
  • do we want new API to affect TLS or not? why?
  • will we have everything soft-disabled reenableable with either priority strings or new-api?
  • will we have priority-string-format keywords for everything, so that a TLS app could forego new-api and only use priority string?
  • if we will have priority-string keywords for everything, can we simplify it somehow? The "priority - soft-disabled +- extra-priority +- new-api - hard-disabled" might be not that hard to merge, but sounds hard to comprehend.
  • how orthogonal are new-api and adding soft-disablement?

And now for something completely different: maybe my original request is misguided. Now I'm not sure why vendors go the disabling way at all (redhat-crypto/fedora-crypto-policies#22). Maybe we should do soft-enabling instead, for writing future-proof config files that don't change effective configuration on gnutls adding new algorithms? Or allow both with smth like default=everything / default=nothing?

This is hard =)


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel