Hi Ted Just some quick general responses, as I still think we have exhausted this list's and subjects attention and are somewhat off the intended topic. Yes, I believe Elliot's suggestions are not only helpful, but understanding of the situation at Enterprises. I just responded to him on this, so I won't elaborate here. Regards to the 12 years vs 1-2. 12 years is probably too long for just about anything, once it is determined to be a business need. But that is the key first step. Then it will likely be a minimum of 1-2 years to get the identified need in the budget and then into planning cycles and actual project plans. For example, if you tell me to do a major conversion right now, it is tool late at this point for me to even request that for the 2021 budget. I could request this in 2021, for the 2022 budget. Hence the typical minimum 1-2 years. Not sure why you say don't buy products that can't be upgraded. I don't think anyone would intentionally do this. And finally, I do agree with you that Elliot has a good feel for the issues being addressed here. I believe I said that to him in my response to his email. This level of understanding and positively proactive attitude towards addressing it is greatly appreciated. I feel the same about Deborah, Barbara and others, and have hope that something more global can happen in this space, outside of this particular email interchange. As far as "Do I think deprecation is coming too soon?" Depends on what you mean by that. I will say that even though I may like to have all pre TLS 1.2 off my network and partner networks by the end of next year, that is unlikely to be accomplished. But since we enterprises were late to this party, and did not get our issues and requirements well known, early on in this process, I will suggest this as a lesson to be better involved or represented, in the future. Hopefully we can learn, and react accordingly. Thanks MIke -----Original Message----- From: Ted Lemon <mellon@xxxxxxxxx> Sent: Friday, December 4, 2020 3:11 PM To: Ackermann, Michael <MAckermann@xxxxxxxxx> Cc: Stephen Farrell <stephen.farrell@xxxxxxxxx>; BRUNGARD, DEBORAH A <db3546@xxxxxxx>; Rob Sayre <sayrer@xxxxxxxxx>; Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx>; Watson Ladd <watsonbladd@xxxxxxxxx>; Eliot Lear <lear=40cisco.com@xxxxxxxxxxxxxx>; last-call@xxxxxxxx; tls-chairs@xxxxxxxx; draft-ietf-tls-oldversions-deprecate@xxxxxxxx; STARK, BARBARA H <bs7652@xxxxxxx>; tls@xxxxxxxx Subject: Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice [External email] On Dec 4, 2020, at 3:00 PM, Ackermann, Michael <MAckermann@xxxxxxxxx> wrote: > 1. Enterprises do not expect nor want IETF to be responsible for their planning for changes in technology. But when IETF decides to change protocols or deprecate existing technology of any sort, it would be beneficial to all if our needs were considered and we were aware of related developments, in an effective and timely fashion. So by this do you mean something like the ops doc Elliot just outlined? If so, we agree that this is at least in principle worth doing, although I don’t know if it’s practical. > 2. No one at any enterprise I am aware even remotely thinks that IETF is making changes to cause us or anyone else trouble. Not even sure why you would say this. The IETF is not as well understood by enterprises as many of us would like, but in no way is it considered a troublemaker, adversary or any of the other things you say below that would make us seem at odds. This area of understanding and communication is another area I hope we can collectively improve, by getting enterprises more engaged, in some fashion or another. I think you misunderstood what I was saying. > 3. No one I am aware of is saying do not deprecate protocols that are obsolete.......... Not TLS or any others. We understand and recognize this need and support it. My comments in this thread were in regards to related timing and the realization that large organizations cannot always be as nimble as most of us technicians would like. And to a small degree I described WHY most enterprises require more time for changes in many cases. This clarifies it a bit. TLS 1.1 was superseded by TLS 1.2 in 2008. This is the 12 years. The process of moving to TLS 1.2 should have started at least when the TLS 1.2 RFC was published, if not before. Not necessarily installing software updates, but there should have been a rollout plan with at most a five year horizon at that point. Clearly there was not; this is what I’m saying needs to change. The time to start planning is not when the protocol is declared "obsolete, do not implement." You should have completed your rollout of the new protocol by this milestone, _at the very latest_. > 4. I don't think I or anyone else has said such changes will take 12 years as you stated. However, 1-2 is usually a base due to budget and planning cycles at large orgs. That’s quite a bit more aggressive than I recall you being in the past, which is good. > 5. I appreciate your advice on which vendors to deal with and how, but I do not view this as a vendor issue and do not have any current issues with any vendors on any related issues. But I do agree, as stated several times in this Email chain, that I would like to see enterprise requirements and engagement much earlier on in IETF processes. You mention 12 years once again referring to how late we are and I am again not sure where that comes from, but I very much hope for earlier on involvement, in the future. What I mean by vendor involvement is that if you have devices that can’t be upgrade, that’s a planning failure. I don’t say that to point fingers, I’m just saying “next time, don’t buy products like that.” Maybe that’s not your issue, but it’s definitely an issue for hospitals, where much of their essential equipment runs Windows 7 or earlier and can’t be upgraded. Expensive equipment, where Windows is a tiny part of the delivered solution. This is disastrous. > 6. Once again, in NO way am I or anyone else saying that the IETF should back off and not say these protocols or any others are not obsolete, not problematic or should not be deprecated. > > I hope the above makes sense and clarifies much of what I was trying to say. IMHO we have taken this as far as we can or should on this list topic, but hopefully improving enterprise and IETF communication/involvement discussions can be continued on other lists or in other fashions, as has been suggested by Barbara and Deborah. Assuming this occurs, and I hope it does, I hope you can be involved, as you are a greatly respected member of the IETF community and could add a lot to that discussion. I think Elliot has probably done a better job of zeroing in on what you are asking for than anyone in this conversation. The one thing that I hear you saying that I still find problematic is that you think the timing of the deprecation is too soon. Am I correct in thinking that’s what I heard? 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
