Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[BRUNGARD, DEBORAH A]

As Stephen said, couldn’t resist, first cup of coffee-

That’s always the question of the day- what is an operator, vendor, researcher?

I know “academia” on this list that have more operational experience than some 
in operator communities. We know in big companies there are so many people - 
but not necessary interested in ietf. And people switch - few are “lifetime” at 
a company. To me, no hats, just want more input.

My point (I think Mike also) is simply to get more involved, earlier if 
possible in our rinse cycle to RFC.

Deborah


From: Rob Sayre 
Sent: Friday, December 4, 2020 12:33 AM
To: Ackermann, Michael
Cc: BRUNGARD, DEBORAH A; Eliot Lear; Peter Gutmann; STARK, BARBARA H; Watson 
Ladd; draft-ietf-tls-oldversions-deprec...@ietf.org; last-c...@ietf.org; 
tls-cha...@ietf.org; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice

Hi,

What is the definition of “enterprise”?

Thanks,
Rob

On Thu, Dec 3, 2020 at 7:48 PM Ackermann, Michael 
mailto:mackerm...@bcbsm.com>> 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 mailto:db3...@att.com>>
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H mailto:bs7...@att.com>>; 'Watson Ladd' 
mailto:watsonbl...@gmail.com>>; Ackermann, Michael 
mailto:mackerm...@bcbsm.com>>
Cc: 'Peter Gutmann' 
mailto:pgut...@cs.auckland.ac.nz>>; 'Eliot Lear' 
mailto:40cisco@dmarc.ietf.org>>; 
'last-c...@ietf.org' 
mailto:last-c...@ietf.org>>; 
'tls-cha...@ietf.org' 
mailto:tls-cha...@ietf.org>>; 
'draft-ietf-tls-oldversions-deprec...@ietf.org'
 
mailto:draft-ietf-tls-oldversions-deprec...@ietf.org>>;
 'tls@ietf.org' mailto:tls@ietf.org>>
Subject: RE: [Last-Call] [TLS] Last Call: 
 (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_B16

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Stephen Farrell]

Hi Michael,

On 04/12/2020 15:14, Ackermann, Michael wrote:


We (Enterprises) are not as involved as we should be in IETF, and
that is our own problem/fault. What I think irritates people like
Stephen,


I'm not irritated at all:-)


is that there have been situations where we finally try to
get involved and provide input/use cases, etc., but at the 11th hour
or after the ship has pretty much sailed.


Getting involved late is just something that happens when
one first gets involved in any new thing so is entirely ok.

If I was irritated (and I'm still not:-), what would have
caused that would be a claim that someone somehow represents
all "Enterprises" and that nobody else has a clue what may
be needed for such networks. I don't buy that at all and
I guess never will, because it just isn't correct.

Cheers,
S.




So as you say Deborah, I very much want to get more Enterprises
involved in IETF initiatives,  but beyond that, being involved up
front in the process (perhaps even making positive contributions
OMG),  rather than only whining about deployment/operational issues
on the back end.   (or explaining why they exist, which is
essentially what I was doing on this issue ☹).

How to accomplish this is a challenge and I think that is what
Barbara suggested taking off to the other list.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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

[Ackermann, Michael]

Deborah
Perhaps my biggest problem is I don’t drink coffee and it is early morning.
But let me try anyway. (maybe I will chug a beer).

I totally agree with you.
We (Enterprises) are not as involved as we should be in IETF, and that is our 
own problem/fault.
What I think irritates people like Stephen, is that there have been situations 
where we finally try to get involved and provide input/use cases, etc., but at 
the 11th hour or after the ship has pretty much sailed.

So as you say Deborah, I very much want to get more Enterprises involved in 
IETF initiatives,  but beyond that, being involved up front in the process 
(perhaps even making positive contributions OMG),  rather than only whining 
about deployment/operational issues on the back end.   (or explaining why they 
exist, which is essentially what I was doing on this issue ☹).

How to accomplish this is a challenge and I think that is what Barbara 
suggested taking off to the other list.

Thanks

Mike


From: BRUNGARD, DEBORAH A 
Sent: Friday, December 4, 2020 9:20 AM
To: Rob Sayre ; Ackermann, Michael 
Cc: Eliot Lear ; Peter Gutmann 
; STARK, BARBARA H ; Watson Ladd 
; draft-ietf-tls-oldversions-deprec...@ietf.org; 
last-c...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice

[External email]
As Stephen said, couldn’t resist, first cup of coffee-

That’s always the question of the day- what is an operator, vendor, researcher?

I know “academia” on this list that have more operational experience than some 
in operator communities. We know in big companies there are so many people - 
but not necessary interested in ietf. And people switch - few are “lifetime” at 
a company. To me, no hats, just want more input.

My point (I think Mike also) is simply to get more involved, earlier if 
possible in our rinse cycle to RFC.

Deborah


From: Rob Sayre mailto:say...@gmail.com>>
Sent: Friday, December 4, 2020 12:33 AM
To: Ackermann, Michael
Cc: BRUNGARD, DEBORAH A; Eliot Lear; Peter Gutmann; STARK, BARBARA H; Watson 
Ladd; 
draft-ietf-tls-oldversions-deprec...@ietf.org;
 last-c...@ietf.org; 
tls-cha...@ietf.org; 
tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice

Hi,

What is the definition of “enterprise”?

Thanks,
Rob

On Thu, Dec 3, 2020 at 7:48 PM Ackermann, Michael 
mailto:mackerm...@bcbsm.com>> 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 mailto:db3...@att.com>>
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H mailto:bs7...@att.com>>; 'Watson Ladd' 
mailto:watsonbl...@gmail.com>>; Ackermann, Michael 
mailto:mackerm...@bcbsm.com>>
Cc: 'Peter Gutmann' 
mailto:pgut...@cs.auckland.ac.nz>>; 'Eliot Lear' 
mailto:40cisco@dmarc.ietf.org>>; 
'last-c...@ietf.org' 
mailto:last-c...@ietf.org>>; 
'tls-cha...@ietf.org' 
mailto:tls-cha...@ietf.org>>; 
'draft-ietf-tls-oldversions-deprec...@ietf.org'
 
mailto:draft-ietf-tls-oldversions-deprec...@ietf.org>>;
 'tls@ietf.org' mailto:tls@ietf.org>>
Subject: RE: [Last-Call] [TLS] Last Call: 
 (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 th

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Ackermann, Michael]

Thanks Stephen

And I would agree that I or no one else can effectively, officially or 
otherwise represent ALL ENTERPISES.In many cases (as I think you have 
witnessed), the very few of us who have showed up at IETF, are even  frequently 
reluctant to represent our OWN Enterprise officially, due to many "Non 
Technical" factors. Unfortunate, but yet another reality of dealing with 
most large corporations and other large orgs.  

But I can say that most large Enterprises are VERY similar in architecture, 
operation, products, and most of all the issues we seem to face.We are even 
MORE similar (scarily so),  within particular industry categories.   So 
there will be a good opportunity to get a pretty realistic view of Enterprise 
requirements, use cases, issues, etc.,  if IETF wants that, which I hope they 
do.  

Thanks again

Mike


-Original Message-
From: Stephen Farrell  
Sent: Friday, December 4, 2020 10:22 AM
To: Ackermann, Michael ; BRUNGARD, DEBORAH A 
; Rob Sayre 
Cc: Eliot Lear ; Peter Gutmann 
; STARK, BARBARA H ; Watson Ladd 
; draft-ietf-tls-oldversions-deprec...@ietf.org; 
last-c...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice


Hi Michael,

On 04/12/2020 15:14, Ackermann, Michael wrote:

> We (Enterprises) are not as involved as we should be in IETF, and that 
> is our own problem/fault. What I think irritates people like Stephen,

I'm not irritated at all:-)

> is that there have been situations where we finally try to get 
> involved and provide input/use cases, etc., but at the 11th hour or 
> after the ship has pretty much sailed.

Getting involved late is just something that happens when one first gets 
involved in any new thing so is entirely ok.

If I was irritated (and I'm still not:-), what would have caused that would be 
a claim that someone somehow represents all "Enterprises" and that nobody else 
has a clue what may be needed for such networks. I don't buy that at all and I 
guess never will, because it just isn't correct.

Cheers,
S.


> 
> So as you say Deborah, I very much want to get more Enterprises 
> involved in IETF initiatives,  but beyond that, being involved up 
> front in the process (perhaps even making positive contributions OMG),  
> rather than only whining about deployment/operational issues
> on the back end.   (or explaining why they exist, which is
> essentially what I was doing on this issue ☹).
> 
> How to accomplish this is a challenge and I think that is what Barbara 
> suggested taking off to the other list.
> 


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

[Andrew Campling]

On Fri, 4 Dec 2020 14:20 BRUNGARD, DEBORAH A 
mailto:db3...@att.com>> wrote:

> As Stephen said, couldn?t resist, first cup of coffee-
>
> That?s always the question of the day- what is an operator, vendor, 
> researcher?
>
> I know ?academia? on this list that have more operational experience than 
> some in operator communities. We know in big companies there are so many 
> people - but not necessary interested in ietf. And people switch - few are 
> ?lifetime? at a company. To me, no hats, just want more input.
>
> My point (I think Mike also) is simply to get more involved, earlier if 
> possible in our rinse cycle to RFC.
>
> Deborah


That does seem to be entirely consistent with the sentiments expressed in RFC 
8890.

Andrew




___
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

[Ted Lemon]

Michael, fundamentally the disconnect here seems to be that the IETF could ever 
be responsible for helping businesses to figure out how to plan for changes in 
technology _other_ than by doing work like this. Deprecating old versions of 
protocols is exactly what the IETF should be doing. This is how the signal 
burbles up through your vendors to you.

I think it’s useful for folks from enterprises to show up and pay attention to 
this, but it’s important to recognize that the reason we are making these 
changes is not to cause you trouble. It’s to try to help you to avoid trouble. 
If you come to the IETF with the goal in mind to get us to not deprecate 
protocols that are obsolete and have known attacks that the newer version of 
the protocol fixes, that’s just not the right model. We aren’t the adversary 
here. The IETF is not causing the protocol to be obsolete. The IETF is simply 
observing that the protocol is in fact obsolete, and it’s past time to stop 
using it. That is, we are observing a fait accompli over which we have no 
control.

The reason we do this is in the hope that you will do what you need to do to 
protect your customers from this fait accompli. The only thing that we could do 
differently is to not try to alert you to this problem.

When it takes twelve years for (some) enterprises to upgrade to the new version 
of a protocol, that’s an indication of some kind of systemic problem. It’s not 
a problem the IETF can solve. What I heard you saying at the beginning of this 
problem was that the IETF needed to understand your operational realities. But 
the implication is that we don’t understand your operational realities. That’s 
not what’s going on here. What’s going on here is that we simply can’t do 
anything about your operational realities.

The fact that we can’t do anything about them does not mean that TLS 1.1 
shouldn’t be deprecated. It just means that you, not the IETF, need to take the 
next step: now that we have told you TLS 1.1 is so obsolete that nobody should 
be using it anymore, you need to integrate that into your planning. You need to 
communicate with your vendors. You need to budget for whatever your plan of 
action is going to be. If you find yourself in an untenable situation because 
of this, you need to learn from that and change your planning methodology so 
that you aren’t caught up short next time a protocol needs to be obsoleted.

Don’t do business with vendors who do not have a plan for how to deal with this 
problem. Get it in the purchasing agreements. Get it in the service provider 
contracts. Begin planning your transition to the new protocol the day it’s 
published, or ideally as soon as you become aware that it’s going to be 
published. Don’t wait until we publish a document twelve years later saying 
that it’s now officially obsolete.

This is a very important problem, and I’m sorry if my previous note made it 
seem like I don’t take it seriously. I do. But it’s not a problem that the IETF 
can solve. If the IETF were to decide not to say that the protocol is obsolete, 
that wouldn’t solve it.  You have the problem whether we tell you you have the 
problem or not.

___
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

[tom petch]

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 
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 
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H ; 'Watson Ladd' <
watsonbl...@gmail.com>; Ackermann, Michael 
Cc: 'Peter Gutmann' ; 'Eliot Lear' ; 'last-c...@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:
 (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  On Behalf Of STARK, BARBARA H

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

To: 'Watson Ladd' ; 'Ackermann, Michael' <
mackerm...@bcbsm.com>

Cc: 'Peter Gutmann' ; 'Eliot Lear' <
lear=40cisco@dmarc.ietf.org>; 'last-c...@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:
 (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 experience

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Ted Lemon]

On Dec 4, 2020, at 3:00 PM, Ackermann, Michael  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?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Carrick Bartle]

I also support adoption.



> On Dec 3, 2020, at 4:17 PM, David Schinazi  wrote:
> 
> I support adoption of draft-vvv-tls-cross-sni-resumption.
> 
> David
> 
> On Thu, Dec 3, 2020 at 1:49 PM Salz, Rich  > wrote:
>  
> 
> Hmmm... I think it probably goes in this draft, but I'm open to being wrong.
>  
> 
> That’s okay with me.
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
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

[Ackermann, Michael]

Thanks Ted
And no, I do not think that you do not take this seriously.   I think we all 
appreciate your  related thoughts and concerns and I thank you for expressing 
them.  

I do think you have misunderstood much of what has been said here.Since 
that is likely my fault, let me try to clarify by responding to directly to 
many of your statements below: 

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

Thanks again for taking this seriously!

Mike


-Original Message-
From: Ted Lemon  
Sent: Friday, December 4, 2020 12:21 PM
To: Ackermann, Michael 
Cc: Stephen Farrell ; BRUNGARD, DEBORAH A 
; Rob Sayre ; Peter Gutmann 
; Watson Ladd ; Eliot Lear 
; last-c...@ietf.org; tls-cha...@ietf.org; 
draft-ietf-tls-oldversions-deprec...@ietf.org; STARK, BARBARA H 
; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice

[External email]


Michael, fundamentally the disconnect here seems to be that the IETF could ever 
be responsible for helping businesses to figure out how to plan for changes in 
technology _other_ than by doing work like this. Deprecating old versions of 
protocols is exactly what the IETF should be doing. This is how the signal 
burbles up through your vendors to you.

I think it's useful for folks from enterprises to show up and pay attention to 
this, but it's important to recognize that the reason we are making these 
changes is not to cause you trouble. It's to try to help you to avoid trouble. 
If you come to the IETF with the goal in mind to get us to not deprecate 
protocols that are obsolete and have known attacks that the newer version of 
the protocol fixes, that's just not the right model. We aren't the adversary 
here. The IETF is not causing the protocol to be obsolete. The IETF is simply 
observing that the protocol is in fact obsolete, and it's past time to stop 
using it. That is, we are observing a fait accompli over which we have no 
control.

The reason we do this is in the hope that you will do what you need to do to 
protect your customers from this fait accompli. The only thing that we could do 
differently is to not try to alert you to this problem.

When it takes twelve years for (some) enterprises to upgrade to the new version 
of 

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Ted Lemon]

On Dec 4, 2020, at 5:29 PM, Ackermann, Michael  wrote:
> Regards to the 12 years vs 1-2.12 years is probably too long for just 
> about anything, once it is determined to be a business need.   But that is 
> the key first step.   Then it will likely be a minimum of 1-2 years to get 
> the identified need in the budget and then into planning cycles and actual 
> project plans.  For example, if you tell me to do a major conversion 
> right now,  it is tool late at this point for me to even request that for the 
> 2021 budget.I could request this in 2021, for the 2022 budget.   Hence 
> the typical minimum 1-2 years. 

But isn’t this the crux of the matter? How do we get to a place where when a 
new version of the protocol comes out, the planning starts? Should the IETF 
have deprecated TLS 1.1 in 2008? That would certainly have given you more lead 
time! I suspect there’s a happy medium.

Why do people buy stuff that’s not upgradeable? Probably because the 
manufacturer doesn’t give them a choice, and there’s no way to force the 
choice. The recent discussions about legally requiring firmware-upgradeable IoT 
devices (e.g. in Singapore) is definitely a step in the right direction. For 
medical devices and medical infrastructure, this should have been required, but 
as far as I know still is not.

I realize that this isn’t your specific problem, but it’s the one that really 
worries me.

___
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

[Ackermann, Michael]

Hi Ted
Just some quick general responses, as I still think we have exhausted this 
list's and subjects attention and are somewhat off the intended topic.   

Yes, I believe Elliot's suggestions are not only helpful, but understanding of 
the situation at Enterprises.I just responded to him on this, so I won't 
elaborate here. 

Regards to the 12 years vs 1-2.12 years is probably too long for just about 
anything, once it is determined to be a business need.   But that is the key 
first step.   Then it will likely be a minimum of 1-2 years to get the 
identified need in the budget and then into planning cycles and actual project 
plans.  For example, if you tell me to do a major conversion right now,  it 
is tool late at this point for me to even request that for the 2021 budget.
I could request this in 2021, for the 2022 budget.   Hence the typical minimum 
1-2 years.  

Not sure why you say don't buy products that can't be upgraded.   I don't think 
anyone would intentionally do this.  

And finally, I do agree with you that Elliot has a good feel for the issues 
being addressed here.  I believe I said that to him in my response to his 
email.  This level of understanding and positively proactive attitude towards 
addressing it is greatly appreciated.I feel the same about Deborah, Barbara 
and others, and have hope that something more global can happen in this space, 
outside of this particular email interchange.
As far as "Do I think deprecation is coming too soon?"   Depends on what you 
mean by that.   I will say that even though I may like to have all pre TLS 1.2 
off my network and partner networks by the end of next year, that is unlikely 
to be accomplished.   But since we enterprises were late to this party, and did 
not get our issues and requirements well known, early on in this process, I 
will suggest this as a lesson to be better involved or represented, in the 
future.   Hopefully we can learn, and react accordingly.  

Thanks

MIke

-Original Message-
From: Ted Lemon  
Sent: Friday, December 4, 2020 3:11 PM
To: Ackermann, Michael 
Cc: Stephen Farrell ; BRUNGARD, DEBORAH A 
; Rob Sayre ; Peter Gutmann 
; Watson Ladd ; Eliot Lear 
; last-c...@ietf.org; tls-cha...@ietf.org; 
draft-ietf-tls-oldversions-deprec...@ietf.org; STARK, BARBARA H 
; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call: 
 (Deprecating TLSv1.0 and TLSv1.1) 
to Best Current Practice

[External email]


On Dec 4, 2020, at 3:00 PM, Ackermann, Michael  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.

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Nick Hilliard]

Ted Lemon wrote on 04/12/2020 22:47:
Why do people buy stuff that’s not upgradeable? Probably because the 
manufacturer doesn’t give them a choice, and there’s no way to force the 
choice. The recent discussions about legally requiring 
firmware-upgradeable IoT devices (e.g. in Singapore) is definitely a 
step in the right direction. For medical devices and medical 
infrastructure, this should have been required, but as far as I know 
still is not.


people don't necessarily buy stuff that's not ungradeable.  They buy 
stuff which has a support lifetime of finite duration.


Manufacturers have no incentive to continue to produce software updates 
for equipment which they stopped selling N years ago, yet the production 
lifetime of the product may well exceed the manufacturer's sales cycle 
for the device.  There aren't credible reasons to think that the problem 
of equipment obsolescence is something that can be fixed by the IETF.


This shouldn't stop the IETF from formally deprecating standards which 
are known to be dysfunctional.


Nick

___
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

[Ted Lemon]

On Dec 4, 2020, at 19:17, Nick Hilliard  wrote:
> people don't necessarily buy stuff that's not ungradeable.  They buy stuff 
> which has a support lifetime of finite duration.

Same thing. If you’re serious about business continuity, you have an 
arrangement with the vendor about what happens if they go out of business, and 
you have an agreement about how long support will last and what it consists of.

Of course no product has infinite lifetime, but lots of iot stuff is expected 
to be in the walls for 30 years. Radiology equipment lasts decades. Etc. 

It’s really natural to think of stuff you buy as being stable and solid, but 
when there’s software in it, this cognitive bias requires serious systems 
thinking to avoid. 
___
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

[Rob Sayre]

On Fri, Dec 4, 2020 at 4:18 PM Nick Hilliard  wrote:

>
> This shouldn't stop the IETF from formally deprecating standards which
> are known to be dysfunctional.
>

The disconnect might be around the term "operator", which some might read
as "wiretap enthusiast".

The IETF should of course deprecate these old TLS versions.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls