Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
> It is incredibly difficult to draw a line so precisely as to where the threat > to a > device begins and ends, given the wide range of deployment scenarios. If a > device can be at all critical (and even if it isn’t), then it should be > upgraded or > replaced. Better that this be out there in its current form so that other > organizations that specify TLS requirements can pick this document up > without any wiggle room or ambiguity. Also, we do not have a “Sometimes > Deprecated” category, nor do I think we should start here. > > Eliot Speaking as someone who has participated in internal discussions on whether to ignore something like this (e.g., even after Wi-Fi Alliance deprecated WEP there was a decision to continue to support WEP for a few years because of the embedded base of non-upgradable devices; same for WPA1), I would suggest the strong, unambiguous statement with explanation for why the statement is being made. There is no need to describe (possible) exceptions. If someone feels a strong need to ignore this in their own network, they will have no difficulty doing so (and have no difficulty justifying it to themselves and others inside their org). I don't think IETF help is needed to figure out these scenarios/reasons/justifications. Barbara > > On 1 Dec 2020, at 10:29, Peter Gutmann > wrote: > > > > Stephen Farrell writes: > > > >> That said, if someone had words to suggest that might garner consensus, > that > >> would be good. > > > > I think all it needs is something along the lines of "This BCP applies to > > TLS > > as used on the public Internet [Not part of the text but meaning the area > that > > the IETF creates standards for]. Since TLS has been adopted in a large > number > > of areas outside of this, considerations for use in these areas are left to > > relevant standards bodies to define". > > > > Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
> >I would suggest the strong, unambiguous statement with explanation > for > >why the statement is being made. > > Yes. > > >There is no need to describe (possible) exceptions. > > My opinion is exactly the opposite. Do describe the exceptions, as precisely > and unambiguously as you can. > > I don't buy the assumption that "one can never figure all the possible reasons > when/why should not apply". Most of the reasons people will use when deciding to continue using these technologies are financially or resource driven (i.e., there are costs to changing) or to ensure a MITM ability to monitor. Getting consensus in IETF that such reasons are "valid" is, in my experience, futile. I really couldn't see IETF getting consensus on any case where the recommendation would be "SHOULD NOT". The only real effect of insisting on such a change to this draft would be to delay its publication indefinitely. I believe it's already past time for these technologies to be deprecated by IETF. The proposed indefinite delay in publication in order to accommodate futile argument is unnecessary and, IMO, harmful. Barbara ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Hi Mike, > As an Enterprise person I can say we are not well equipped to be aware of > nor react "Nimbly" to changes such as this. Wide scope and security related > changes can require major changes to core Business systems. This can mean > significant time, effort and/or $$$. I have to disagree with you. In my experience, enterprises have shown themselves to be extremely well-equipped and capable of ignoring (and even being blissfully unaware of) IETF RFCs wrt their internal networks when they so choose. For example, IPv6 deployment. 😊 But the fact that the US government (and other governments) have already deprecated use of these technologies inside govt networks is probably something enterprises who do business with governments can't ignore (unlike IETF RFCs). > The biggest barrier is that this topic is not currently on the Planning or > Budget > radar at all, and usually takes 1-2 years (or more) to achieve either. I see no barrier to enterprises ignoring IETF RFCs wrt their internal networks. But I'm surprised that US enterprises who contract with the US federal govt wouldn't have put this on their radar long ago, since the NIST first draft proposing deprecating these appeared 3 years ago, and the NIST SP 800-52 Rev. 2 final version (officially deprecating them) was published over a year ago. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf See Section 3 for minimum requirements for TLS servers and Appendix F for a specific discussion of TLS 1.0 and 1.1 client support. > On one side of such issues, I don't think IETF understands the above and on > the other side Enterprises are unaware of developments at IETF and other > SDO's.Bridging that important gap is not unique to this topic. This IETF BCP will be very easy for enterprises to ignore wrt their internal networks. There is no need for enterprises to be aware of this BCP. But it may behoove some enterprises to be aware of documents their govts have published. Barbara > -Original Message- > From: TLS On Behalf Of Eliot Lear > Sent: Wednesday, December 2, 2020 5:54 AM > To: Peter Gutmann > Cc: draft-ietf-tls-oldversions-deprec...@ietf.org; last-c...@ietf.org; STARK, > BARBARA H ; tls@ietf.org; tls-cha...@ietf.org > Subject: Re: [TLS] [Last-Call] Last Call: > 09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice > > [External email] > > > > On 2 Dec 2020, at 11:44, Peter Gutmann > wrote: > > > > > > It's actually the complete opposite, they will have every difficulty > > in doing so. You've got systems engineers whose job it is to keep > > things running at all costs, or where the effort to replace/upgrade is > > almost insurmountable, who now have to deal with pronouncements from > > standards groups that insist they not keep things running. I don't > > know where you get this idea that this will cause "no difficulty" > > from, it's a source of endless difficulty and frustration due to the > > clash between "we can't replace or upgrade these systems at the > > moment" and "there's some document that's just popped up that says we > need to take them out of production and replace them”. > > > That is as it should be. Let everyone understand the risks and make > informed decisions. This draft does an excellent job at laying out the > vulnerabilities in TLS 1.0 and 1.1. What it cannot do is adjudicate risk in > every > situation. If someone has done so and decided that the risk is acceptable, > very well. They went in eyes wide open, and Stephen and friends helped. > > Eliot > > > > > > > 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Hi Mike, I think you may have mis-read some of my comments as being about NIST IPv6 requirements. They weren't. We're talking about TLS. They were specifically about a NIST publication that requires certain servers to support TLS 1.2 (at a minimum) and to be very carefully when justifying support for clients that can't do at least TLS 1.2. Here are quotes: "Servers that support government-only applications shall be configured to use TLS 1.2 and should be configured to use TLS 1.3 as well. These servers should not be configured to use TLS 1.1 and shall not use TLS 1.0, SSL 3.0, or SSL 2.0." "Servers that support citizen or business-facing applications (i.e., the client may not be part of a government IT system) shall be configured to negotiate TLS 1.2 and should be configured to negotiate TLS 1.3. The use of TLS versions 1.1 and 1.0 is generally discouraged, but these versions may be configured when necessary to enable interaction with citizens and businesses. See Appendix F for a discussion on determining whether to support TLS 1.0 and TLS 1.1. These servers shall not allow the use of SSL 2.0 or SSL 3.0." The final version of this was published over a year ago (August 2019). The first draft was in 2017. You said enterprises needed 1-2 years (or more) lead time. In the US, I think they've had at least 3 years lead time, so far. Note that deprecation doesn't immediately make functionality disappear. The code will continue to exist (possibly for decades to come, until whatever language and operating systems it runs on become completely obsolete). But these technologies are widely known to be insecure. The deprecation statement needs to be made. How system providers and enterprises and other deployers react to the deprecation is up to them. I've seen some deprecated technologies take many years to truly disappear from deployment -- from WEP to WPA1 to TDMA to BBF TR-098 (which shows no signs of disappearing) to many others. Deprecation is the first step in driving these technologies out of deployments. It's not the final step. In order to try to prevent future ransomware attacks like what NIH and the City of Atlanta and many others experienced because they continued to use obsolete technology, we absolutely, positively have to take this first step. IETF can't force enterprises to be responsible. But IETF needs to be as forceful and unambiguous as possible -- now (actually, last year, or so) -- in recommending these technologies stop being used. [And let's be clear -- NIH and various cities made exactly this judgment call that replacing insecure, obsolete technology was "too expensive" and "unnecessary". The ransomware attacks turned out to be much, much more expensive; and made the necessity very obvious. They may have cost lives as well as money. I'm not willing to be the person who tries to figure out the relative value of lives vs. money spent today, or try to gauge how many lives might be acceptably lost in order to make enterprises feel more comfortable about delaying deploying better security. Going back to IPv6 -- I'm actually fine with sitting back and letting enterprises figuring out what makes sense for them wrt IPv4 vs. IPv6; but I'm passionate about the need to push for deploying secure technology and getting rid of obsolete and insecure technology.] Barbara > Thanks Barbara, > My responses are inline below. > > -Original Message- > From: STARK, BARBARA H > Sent: Wednesday, December 2, 2020 11:20 AM > To: Ackermann, Michael ; 'Eliot Lear' > ; 'Peter Gutmann' > > Cc: 'draft-ietf-tls-oldversions-deprec...@ietf.org' > deprec...@ietf.org>; 'last-c...@ietf.org' ; 'tls@ietf.org' > ; 'tls-cha...@ietf.org' > Subject: RE: [TLS] [Last-Call] Last Call: > 09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice > > [External email] > > > Hi Mike, > > > As an Enterprise person I can say we are not well equipped to be aware > > of nor react "Nimbly" to changes such as this. Wide scope and > > security related changes can require major changes to core Business > > systems. This can mean significant time, effort and/or $$$. > > I have to disagree with you. In my experience, enterprises have shown > themselves to be extremely well-equipped and capable of ignoring (and > even being blissfully unaware of) IETF RFCs wrt their internal networks when > they so choose. For example, IPv6 deployment. 😊 > NOT SURE WHAT WE ARE DISAGREEING ABOUT HERE?ENTERPRISES BEING > UNAWARE IS A ONE OF THESE REASONS THAT THIS TOPICS ARE NOT ON OUR > PLANNING RADAR OR IN PROJECTED BUDGETS. > But the fact that the US government (and other governments) have already > dep
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Ow! Mike is my friend. Don't go dissing my friend! I think the problem in communication we've just experienced is because Mike strayed away from Last Call discussion on a specific document, to asking/discussing a more general question of how IETF can better communicate with enterprises and perhaps even engage with enterprises to make it easier to operationalize protocols inside enterprise networks. I didn't see Mike suggesting any changes to the draft in Last Call, relevant to this question. ? I'd like to suggest that maybe we could discuss this a little more on the ietf list? But not here. I'll see what happens if I start a thread over there (i...@ietf.org) ... Barbara [Let me drum up my courage first. Thinking about posting to that list is much more stressful to me than, for example, thinking about bungie jumping off the Macau Tower -- an experience I highly recommend.] > > Barbara, > > Thanks. > > And I think I was aware of all you state below regarding TLS, and apologize > for any related confusion regarding IPv6, even though, for the purposes of > my comment, they are similar. > > > > > > I don't disagree with anything you say on the TLS subject, which is > essentially that prior versions of TLS may be considered insecure, etc. and > should be deprecated. > > Shouldn't we publish a document saying that? It seems this would > represent consensus, even your view of the issue. > > > > > My associated point is that Enterprises are generally not aware of this and > that it is not currently on our Planning or Budget Radars. > > > TLS 1.2 has been around for how many years? All versions of OpenSSL > without support have been EOL for some time. How many other CVE remain > to be found in them? FIPS, PCI etc are all very clear that old TLS is > going away. Browsers have supported TLS 1.2 for years. So has Windows. > This depreciation should be easy given the extent of support for TLS > 1.2. > > I bet that most services you run are already using TLS 1.2 or even 1.3 > because the client and server have been updated. > > > Further, this means we are potentially years from effectively and > operationally addressing such issues. > > Let's be about it. > > >And we must do so in conjunction with Partners, Clouds, Clients and > others. > > And my general, overall point is that the answer to addressing the above is > to find way(s) of making Enterprises aware and possibly assisting with > methods of addressing. I think I also said this problem is not unique to > TLS > or IPv6. More, it is a lack of understanding of how things work within > Enterprise Networks and the lack of Enterprise engagement in Standards > Development processes. > > And finally, this may not be a gap that the IETF should care about or > address, but someone should, IMHO. > > Your argument against the current text seems to be the following: we > have a problem. It is inconvenient for me that you will ask me to deal > with the problem. Therefore I would like the problem to not be > acknowledged. > > Perhaps I am being too uncharitable. But I fail to see how softening > the language eases depreciation, or what the consequence you fear > happening are. You're free to continue ignoring the RFC series. But > reality does not go away if it is ignored. > > Sincerely, > Watson Ladd > > > > > Thanks > > > > Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
