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

["BRUNGARD, DEBORAH A" <[e-mail]>]

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 <[e-mail]> On Behalf Of STARK, BARBARA H
Sent: Thursday, December 3, 2020 12:03 PM
To: 'Watson Ladd' <[e-mail]>; 'Ackermann, Michael' <[e-mail]>
Cc: 'Peter Gutmann' <[e-mail]>; 'Eliot Lear' <lear=[e-mail]>; '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>
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 ([e-mail]) ...
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
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!BhdT!1mNyW_HOYqxvO6jkrkE01zLoel9zrEb9Om34gLPLPqvikiDKKm4gJz3zSSrsDXk$