TLSRoute SNI match inconsistency

[howardjohn]

TLS route:

spec:
  rules:
  - matches:
    - snis: ["foo.com"]
    forwardTo:
    - serviceName: httpbin
      port: 443

HTTP route:

spec:
  hostnames: ["foo.com"]
  rules:
  - forwardTo:
    - serviceName: httpbin
      port: 80

The inconsistency here feels a bit odd when compared to HTTPRoute.

Would it make sense to make a hostnames field in TLSRoute and remove the snis field in matches? Then the specs above would be identical (both looking like the "HTTP Route")

[bowei]

Discussion from meeting, looks like there are two threads:

1. General support for making TLSRoute consistent with HTTP Route. This is a tradeoff with the user having to create multiple TLSRoute objects as opposed to one that is aggregate'd single object.

2. Changing the name to hostnames --

There is room in the TLS spec for different types of matching there. Whether or not it is realistic that we will see any changes here in TLS is a valid question:

From: https://tools.ietf.org/html/rfc6066#section-3

struct {
          NameType name_type;
          select (name_type) {
              case host_name: HostName;
          } name;
      } ServerName;

      enum {
          host_name(0), (255)
      } NameType;

      opaque HostName<1..2^16-1>;

      struct {
          ServerName server_name_list<1..2^16-1>
      } ServerNameList;
}

[hbagdi]

Changing the name to hostnames

I think you mean sni.
One reason I can make against changing it is that if the core routes are homogenous, custom routes might take that as a hint to reuse hostnames for a field that seems similar to HTTP hostname.

If snis feels a bit too specialized or archaic (although, I don't see how, anyone using a TLSRoute MUST know the concept of SNI to use it correctly), how do folks feel about servernames instead?

[howardjohn]

I think you mean sni.

I cannot speak for Bowei but my proposal was to make TLSRoute identical to HTTPRoute (ie hostnames at top level). Its a bit of bikeshedding/personal preference, but I see them the same:

• HTTPRoute hostnames looks in Host header to see which hostname a request was intended for
• TLSRoute hostnames looks in SNI to see which hostname a request was intended for

[bowei]

John -- I think we can go head with a PR for the first bullet and keep discussing the sni vs hostnames.

[hbagdi]

/assign