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

["Ackermann, Michael" <MAckermann@xxxxxxxxx>]

Elliot

 

Quite a bit of what you say would be helpful. 

 

Enterprises are in need of a lot of assistance and information on many topics and will take help wherever we can get it.   And BTW, if you think we are slow on TLS versions,  then please do not even ask about IPv6 😊.   

 

So I think there would be interest in all that you talk about below,  but the biggest areas of concern, IMHO might be:

 

• Finding out how much TLS 1.0, 1.2 and 1.3 is on our networks today.   And Sadly, we will likely find old versions of SSL as well.
• Determining which devices, OS’s,  or software products are capable of which versions of TLS.   And what related upgrade paths exist (if any are available). 
• How changes will affect network management/monitoring.  (which I think is what you meant by Debugging, which is an important subset). 

 

I think you are suggesting similar things below and more, which gives me a great feel that you understand the issues we will face and on many issues, how to address them.   Thanks so much for that!

 

I think there would be great interest in something like this, but in terms of how to deliver, I am not aware of what LISA is?

 

Thanks again!

 

Mike

 

 

 

 

From: Eliot Lear <lear@xxxxxxxxx>
Sent: Friday, December 4, 2020 12:57 PM
To: Ted Lemon <mellon@xxxxxxxxx>
Cc: Ackermann, Michael <MAckermann@xxxxxxxxx>; last-call@xxxxxxxx
Subject: Next steps on Deprecation/Obsolescence of TLS 1.0/1.1 Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

 

[Reducing a bit]

 

Ted,

 

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.

 

Eliot

On 4 Dec 2020, at 18:20, Ted Lemon <mellon@xxxxxxxxx> wrote:

 

Michael, fundamentally the disconnect here seems to be that the IETF could ever be responsible for helping businesses to figure out how to plan for changes in technology _other_ than by doing work like this. Deprecating old versions of protocols is exactly what the IETF should be doing. This is how the signal burbles up through your vendors to you.

I think it’s useful for folks from enterprises to show up and pay attention to this, but it’s important to recognize that the reason we are making these changes is not to cause you trouble. It’s to try to help you to avoid trouble. If you come to the IETF with the goal in mind to get us to not deprecate protocols that are obsolete and have known attacks that the newer version of the protocol fixes, that’s just not the right model. We aren’t the adversary here. The IETF is not causing the protocol to be obsolete. The IETF is simply observing that the protocol is in fact obsolete, and it’s past time to stop using it. That is, we are observing a fait accompli over which we have no control.

The reason we do this is in the hope that you will do what you need to do to protect your customers from this fait accompli. The only thing that we could do differently is to not try to alert you to this problem.

When it takes twelve years for (some) enterprises to upgrade to the new version of a protocol, that’s an indication of some kind of systemic problem. It’s not a problem the IETF can solve. What I heard you saying at the beginning of this problem was that the IETF needed to understand your operational realities. But the implication is that we don’t understand your operational realities. That’s not what’s going on here. What’s going on here is that we simply can’t do anything about your operational realities.

The fact that we can’t do anything about them does not mean that TLS 1.1 shouldn’t be deprecated. It just means that you, not the IETF, need to take the next step: now that we have told you TLS 1.1 is so obsolete that nobody should be using it anymore, you need to integrate that into your planning. You need to communicate with your vendors. You need to budget for whatever your plan of action is going to be. If you find yourself in an untenable situation because of this, you need to learn from that and change your planning methodology so that you aren’t caught up short next time a protocol needs to be obsoleted.

Don’t do business with vendors who do not have a plan for how to deal with this problem. Get it in the purchasing agreements. Get it in the service provider contracts. Begin planning your transition to the new protocol the day it’s published, or ideally as soon as you become aware that it’s going to be published. Don’t wait until we publish a document twelve years later saying that it’s now officially obsolete.

This is a very important problem, and I’m sorry if my previous note made it seem like I don’t take it seriously. I do. But it’s not a problem that the IETF can solve. If the IETF were to decide not to say that the protocol is obsolete, that wouldn’t solve it.  You have the problem whether we tell you you have the problem or not.

 

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

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