Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux