As Barbara builds her confidence for the IETF list and while we have Mike's attention-
Mike, you commented "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." I wanted to +1 on to Barbara's message - many of us will say - "we do care". As IETF is "huge" (for many operators/users that is the biggest bottleneck on participating), not sure if you follow the ops area (I'm a routing AD, but ops always has my attention😊), they have several documents on enterprises. Currently a document on the impact of TLS1.3 on operational network security practices. They also have an IPv6 one. I think in all the Areas (I know best the routing area), we encourage operators and users to participate. If you have suggestions - we are interested. How to increase visibility? Do you have suggestions? Liaisons? ISOC? When RFC7381 (Enterprise IPv6) was done, it was an ISOC blog: https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/ Possibly this draft should be a blog? Suggestions? Thanks again for the interesting thread- Deborah for some humor - I'm still stumbling on the draft's requirement "Pragmatically, clients MUST NOT send". I'm not sure operationally how to ensure pragmatic client behavior - maybe a "pragmatic client" profile😊 I'll save that question for my ballot comment. And of course a google of pragmatic is very entertaining: https://www.google.com/search?q=pragmatic&tbm=isch&source=iu&ictx=1&fir=UnkLahjDGGZYtM%252C2VmBAP_98FtW_M%252C%252Fm%252F0c6h9&vet=1&usg=AI4_-kQHPVOk9B-3gfzcXUP1bBCiuOQ5TQ&sa=X&ved=2ahUKEwjxqN-W1rLtAhXKhK0KHWuFBGYQ_B16BAgrEAE#imgrc=WzKrFQWEFvjiWM -----Original Message----- From: last-call <last-call-boun...@ietf.org> On Behalf Of STARK, BARBARA H Sent: Thursday, December 3, 2020 12:03 PM To: 'Watson Ladd' <watsonbl...@gmail.com>; 'Ackermann, Michael' <mackerm...@bcbsm.com> Cc: 'Peter Gutmann' <pgut...@cs.auckland.ac.nz>; 'Eliot Lear' <lear=40cisco....@dmarc.ietf.org>; 'last-c...@ietf.org' <last-c...@ietf.org>; 'tls-cha...@ietf.org' <tls-cha...@ietf.org>; 'draft-ietf-tls-oldversions-deprec...@ietf.org' <draft-ietf-tls-oldversions-deprec...@ietf.org>; 'tls@ietf.org' <tls@ietf.org> Subject: Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (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 -- last-call mailing list last-c...@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!BhdT!1mNyW_HOYqxvO6jkrkE01zLoel9zrEb9Om34gLPLPqvikiDKKm4gJz3zSSrsDXk$ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
