GatewayTLSConfig: Well known options

[nickethier]

Hi folks, I'm working on the HashiCorp Consul Gateway API integration 👋🏼

One of our requirements is to be able to configure the TLS min version the gateway will accept. I'm planning on exposing that as an available option in the GatewayTLSConfig options map for our implementation. Has there been any discussion around a set of GatewayTLSConfig options with well-known keys/values that are perhaps candidates to eventually have their own field?

For example, instead of us defining the implementation specific key api-gateway.consul.hashicorp.com/tls_min_version namespace it under gateway.networking.k8s.io and document the well known values.

[jpeach]

There hasn't been any discussion on specific options that I'm aware of, though I've always assumed many options like this would be standardized. The timing on this might be a bit early (would be interesting to see the intersection of options across implementations), but I expect that a proposal standardizing the TLS options vocabulary would be well received.

[hbagdi]

How do folks feel about standardizing on these options but without any sort of conformance definition (or just implementation-specific)?
Not doing this will probably lead to a bunch of annotations or keys (like Ingress) - something we should avoid for at least very common features.

[howardjohn]

Sounds reasonable. I don't see any good reason to have 5 different ways to say "tls min version" 🙂

[youngnick]

Agreed. For things that are definitely common, I think this is a good idea.

[bowei]

Make sense -- we can promote to a legitimate fields as they stabilize. I think we tried to standardize semantics of stuff like min, max version, but it wasn't super successful in the initial proposal.

[jpeach]

Make sense -- we can promote to a legitimate fields as they stabilize.

One approach is to do nothing for 6 months and let implenentations deal with it, then come back and standardize the overlap. More churn for implementations but less chance of getting it wrong.

[youngnick]

If we're going to wait, we should definitely ensure that the implementation-slpecific things must be namespaced something.somedomain/setting-name style names, so we don't end up with overlap.

[mikemorris]

One specific thing I noticed while starting on implementation for this functionality is that Envoy allows specifying a different TLS minimum and maximum version for incoming (downstream) versus outgoing (upstream) connections, and currently defaults to supporting incoming TLS 1.3 connections but only initiating outgoing TLS 1.2 connections. I'm curious if other proxies have a similarly configurable split, and if supporting that distinction would make sense in the future for well-known option keys in the Gateway API spec?