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 04/12/2020 05:32, Rob Sayre wrote:
Hi,

What is the definition of “enterprise”?


You could try the 16 RFC with 'enterprise' in their title such as RFC7381.

Perhaps those who use as opposed to operators who provide, those whose business is funded by those who have little or no interest in what the IETF does, just in making or serving or selling or operating physical transport or ... anything but a network and getting paid for doing so; and who only take notice of security after the disaster has struck and now can see the cost of not having security by way of fines from state bodies, loss of customers who no longer have trust, ransom payments and such like. I speak from a little experience in this area, of being told that they wished they had listened to my advice but only after disaster had struck although here I am speaking more generally than just of security breaches.

Tom Petch

Thanks,
Rob

On Thu, Dec 3, 2020 at 7:48 PM Ackermann, Michael <MAckermann@xxxxxxxxx>
wrote:

Deborah

Thanks so much for your informative and positive message.

I have not followed the OPs area too much, but will make an effort to do
so now.   Any specific drafts you might suggest, I will review.   In
particular,  I am interested in what specific IPv6 document from the OPs
area you refer too?



I took a look at the ISOC IPv6 doc you listed.   Interesting but it
appears to be quite old.   Do you feel it is still relevant?    Enterprises
need a lot of info on IPv6 and I want to point them in the most effective
directions.

By increasing visibility, do you mean ways to get Enterprises more
involved or aware of IETF?     I can sadly say none that have yet been
effective, but I do intend to keep trying.   Perhaps you have ideas?



And finally, I checked out your Pragmatic Link.  Still laughing, even
though it unfortunately seems to have very little relevance to my world 😊



Once again I really appreciate your constructive comments and
  information.



Mike



-----Original Message-----
From: BRUNGARD, DEBORAH A <db3546@xxxxxxx>
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H <bs7652@xxxxxxx>; 'Watson Ladd' <
watsonbladd@xxxxxxxxx>; Ackermann, Michael <MAckermann@xxxxxxxxx>
Cc: 'Peter Gutmann' <pgut001@xxxxxxxxxxxxxxxxx>; 'Eliot Lear' <lear=
40cisco.com@xxxxxxxxxxxxxx>; 'last-call@xxxxxxxx' <last-call@xxxxxxxx>; '
tls-chairs@xxxxxxxx' <tls-chairs@xxxxxxxx>; '
draft-ietf-tls-oldversions-deprecate@xxxxxxxx' <
draft-ietf-tls-oldversions-deprecate@xxxxxxxx>; 'tls@xxxxxxxx' <
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]





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-bounces@xxxxxxxx> On Behalf Of STARK, BARBARA H

Sent: Thursday, December 3, 2020 12:03 PM

To: 'Watson Ladd' <watsonbladd@xxxxxxxxx>; 'Ackermann, Michael' <
MAckermann@xxxxxxxxx>

Cc: 'Peter Gutmann' <pgut001@xxxxxxxxxxxxxxxxx>; 'Eliot Lear' <
lear=40cisco.com@xxxxxxxxxxxxxx>; 'last-call@xxxxxxxx' <last-call@xxxxxxxx>;
'tls-chairs@xxxxxxxx' <tls-chairs@xxxxxxxx>;'
draft-ietf-tls-oldversions-deprecate@xxxxxxxx' <
draft-ietf-tls-oldversions-deprecate@xxxxxxxx>; 'tls@xxxxxxxx' <
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



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 (ietf@xxxxxxxx) ...

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-call@xxxxxxxx


https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!BhdT!1mNyW_HOYqxvO6jkrkE01zLoel9zrEb9Om34gLPLPqvikiDKKm4gJz3zSSrsDXk$
<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/last-call__;!!BhdT!1mNyW_HOYqxvO6jkrkE01zLoel9zrEb9Om34gLPLPqvikiDKKm4gJz3zSSrsDXk$>

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





--
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