Re: [Last-Call] Next steps on Deprecation/Obsolescence of TLS 1.0/1.1 Re: [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Ted Lemon <mellon@xxxxxxxxx>]

On Dec 4, 2020, at 12:57 PM, Eliot Lear <lear=40cisco.com@xxxxxxxxxxxxxx> wrote:

Thanks for this note.  I think actually there is something the IETF can do, and this is the part of the discussion I like.  Here are a few examples:

• Blog that this is coming, and talk a little about the implications.
• Write an operational guide to handling these sorts of changes.

On that latter bullet, Fred and I did that early on with IPv6 to talk a little about renumbering in that environment.  It wasn’t meant as a standard, but just guidance.  Here we could say a few things:

• Understanding some of the issues:
• Some devices don’t speak > 1.1; some devices don’t speak < 1.2
• Only a problem if they have to interact
• What log messages to look for when there is a problem.
• Special considerations for customer-facing services
• Warn customers
• Load balancer issues
• Debugging changes
• Anomaly detection changes (if any)
• Having an inventory of devices that are on one’s network is a good thing.
• Knowing which of those devices is using TLS 1.0/1.1 is important.
• Here’s how to detect version information, perhaps with Wireshark, tcpdump, etc.
• Options for devices:
• Upgrade plan
• Obsolescence
• Front end proxy

Now it is possible that this is a document that should go to LISA or some place like that, but it doesn’t seem like a bad BCP, if there is interest.

To be clear, it has felt like Michael is arguing that we shouldn’t deprecate TLS 1.1, or maybe that we should have communicated this better and earlier. The first goal seems perhaps to have evolved into the second, and that’s good news. Perhaps I was wrong in thinking that the first position was ever the goal, but that’s how I read it, and was the point I was speaking to.

If we agree with the second interpretation of Michael’s point, then what you are proposing would certainly be what we should have done better and earlier, but might as well do now.

That said, this is an unsolvable problem if enterprises continue to operate under the assumption that it is ever okay to purchase any device or service that doesn’t have a clearly defined upgrade path. This is the operational practice that I don’t think IETF is competent to address. Regulations and enforcement would help. Having worked at a bank in the past, I know what FDIC audits look like. Enterprise generally tries to avoid audits of this sort, but they can be fairly effective, at least from a network security perspective. The point being, this is something that a functioning government, if such a thing yet exists in this world, could do to improve the situation going forward. I would argue that as individuals, we should be doing what we can to communicate to our elected representatives (if we live in a functioning democracy) that this is necessary.

What you are proposing is a document about what to do given the situation we have sleepwalked into. I think that’s good too. This is something that the IETF could conceivably do, although some of your action items above (e.g. what log messages to look for) sound impossible. Still, I would not object to doing this work in v6ops if there’s energy for it; not sure how much I’d have to contribute that someone else wouldn’t be more qualified to contribute.

But the bottom line is that deprecating TLS 1.0 and 1.1 is the right thing to do, and now is a better time to do it than now+x, for all positive values of x. None of what we are discussing in terms of mitigation strategies changes that in any way.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call