[GitHub] [trafficcontrol] rob05c commented on a change in pull request #5851: Delivery Service Supported TLS Versions Blueprint

[GitBox <gi...@apache.org>]

rob05c commented on a change in pull request #5851:
URL: https://github.com/apache/trafficcontrol/pull/5851#discussion_r640141317



##########
File path: blueprints/delivery.service.tls.versions.md
##########
@@ -0,0 +1,358 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Delivery Service TLS Versions
+
+## Problem Description
+Currently, supprted TLS versions cannot be configured. This means that a
+Delivery Service can have clients requesting its content over old, insecure
+versions of TLS, and Tenants controlling that Delivery Service have no way to
+force clients to use more recent versions.
+
+## Proposed Changes
+Changes to ATS in version 8.1 allow cache server configuration generation to
+produce configuration files that can effectively control the TLS versions
+allowed by a Delivery Service, causing clients using other versions to result
+in request failure. Currently, (in unreleased behavior on the master branch),
+this is implemented using a Delivery Service Profile Parameter. However,
+Parameters are notorious for being unvalidated, unstructured data that can be
+just obscure enough to escape notice, even when properly documented. For the
+best possible user, operator, and developer experiences, the data should be
+formally added to Delivery Service objects.
+
+## Data Model Impact
+Delivery Service objects will be augmented to include a set of allowed TLS
+versions for the Delivery Service's content. Specifically, They will be
+expanded to implement this interface:
+
+```typescript
+interface TLSVersionSpecifier {
+	tlsVersions: [string, ...Array<string>] | null;
+}
+```
+
+For those not super familiar with Typescript, this interface specifies a
+`tlsVersions` property that can be either null, or an array of N strings,
+where N is *at least one*. In other words, this can be null, but cannot be an
+empty array.
+
+The reason for this is best understood by first understanding what `null` means
+for this field. If `tlsVersions` is `null`, it means that no TLS version
+restrictions in place; the behavior is the same as today without the field, all
+TLS versions are implicitly supported.
+
+An empty array would seem to signify that no TLS versions are supported, which

Review comment:
       I'm not strictly a -1, but UI hacks like this are poor design. It shouldn't be possible for users to assign TLS versions to an HTTP service. If the system can't handle that, we should fix the system.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org