[recipient list trimmed to just ietf@] On 12/9/20 1:21 AM, Christian Huitema wrote:
We could look at process, or we could look at technology. Take for example one of the updated RFC, 3856, "A Presence Event Package for the Session Initiation Protocol (SIP)". The text says that it basically uses TLS to secure the connection. Changing the version of TLS has no functional impact on the specification, which relies only on version-independent properties of TLS such as confidentiality and authentication. The text only mentions a "version" of TLS through its references to RFC 2246, TLS 1.0, which was the version of TLS current at the time. Yes, the authors of that RFC did not write "TLS 1.0 or a later version". Had they done that, there would be no process issue. And I think that if we want a narrow process decision, we should start there: applications should anticipate that security requirements will change over time, and say something like "current version of TLS [RFC XXXX] or later."
I certainly agree that the majority of specifications that reference TLS version X SHOULD NOT be updated when TLS version X falls from favor and TLS version X+n is now considered the minimum version that's appropriate for use. Revising any RFC can be like opening Pandora's box, because the new RFC is then expected to meet current document standards for boilerplate, references and dependencies, language, and who knows what else. It also introduces the potential to find new issues and rehash old ones. None of those things is inherently bad by itself, but together they can require an immense effort for usually marginal benefit. The revision may even increase the potential for confusion in the community of RFC users as they try to reconcile minor differences between versions.
And yet, one of the problems with SSL 1.0 and all subsequent versions seems to be the notion that you can wave a magic wand and create "security" as a black box that applications or users don't have to worry about. I would argue that in some cases, applications DO need to worry about that layer, and dealing with version transitions is arguably one of those cases. Because the Right Thing to happen when the encryption layer needs to improve based on new threats is almost never for existing services that people depend on to fail suddenly and/or for no apparent reason, and not every use of TLS is an interactive application with a user in the loop who can understand the problem and initiate corrective action.
I'm reminded again that successful transitions often need more than one step before they reach the desired final state, just as it's easier to cross a stream by stepping on a stone or two along the way than to try to leap across the whole thing. (And in the absence of such stepping stones or a bridge or ferry or whatever, some people may find themselves unable to cross.) Maybe it's worth trying to find a better way to upgrade TLS before we discover that TLS 1.2 needs to be deprecated.
Keith
