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

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Dec 2020 09:29:01 +0000

Stephen Farrell <[email-masked]> 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.

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Dec 2020 07:57:46 -0500

On 12/1/20 4:29 AM, Peter Gutmann wrote:

> the IETF creates standards for].

Not specifically relevant to this draft, but:  Is it actually defined 
anywhere that IETF standards only apply to the public Internet?  IMO 
IETF needs to realize that implementations of its standards are used 
outside of the public Internet and consider that when writing its 
documents.  (even though different rules may be appropriate on private 
and mostly-isolated networks)

Keith

p.s. I keep thinking that this "MUST NOT TLS < 1.2" recommendation is 
like a public health recommendation, one that is worded over-simply to 
try to make it have maximum useful effect but perhaps to the point of 
being misleading or even harmful. e.g. "You MUST wear masks to reduce 
the spread of COVID-19", but not saying "oh yeah, if you're outdoors and 
not around other people you're probably fine without a mask" and "masks 
are pointless if you only wear them over your mouths or chins", and "the 
masks that have valves in them to allow exhaled breath to exit unimpeded 
are also useless for this purpose" and "you need to wear them when 
indoors and around co-workers, not merely when customers or visitors are 
present".  At least where I live I see so many people using masks in 
ineffective ways that I don't think the simple recommendation is 
working, though I'm not sure that a more detailed recommendation would 
work better.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Dec 2020 13:53:33 +0000

The right thing to do, from a security viewpoint, is DO NOT USE TLS 1.0 OR TLS 1.1 If you have special circumstances, then do not follow the RFC (once published).

If not following the RFC makes some people uncomfortable, that’s their bug.  We should not water down our recommendations.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Dec 2020 14:11:57 +0000

On 12/1/20, 4:29 AM, "Peter Gutmann" <[email-masked]> wrote:

I think it should be phrased the other way, as in
	There are some environments (e.g., a network which has no connectivity to the public Internet), where this BCP need not apply.

I don't care what the wording is, but I think the right way to approach this is to carve out an exception for those who will be upset by the recommendation.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Dec 2020 14:50:54 +0000

Salz, Rich <rsalz=[email-masked]> writes:

>The right thing to do, from a security viewpoint, is DO NOT USE TLS 1.0 OR
>TLS 1.1 If you have special circumstances, then do not follow the RFC (once
>published).

And how will the people who can ignore it know that it's OK for them to do so?
Once it's published, everyone who uses TLS will think it applies to them
personally even when it doesn't.  This is why putting wording in there telling
these groups that it doesn't apply to them would be a good proactive move.

Peter.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 1 Dec 2020 16:05:28 +0100

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

> On 1 Dec 2020, at 10:29, Peter Gutmann <[email-masked]> wrote:
> 
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Dec 2020 15:21:04 +0000

>    And how will the people who can ignore it know that it's OK for them to do so?

Well, frankly, that's not our problem.  If someone is going to blindly insist on RFC conformance and doesn't recognize the wording that says "might not apply to you" ... well, so be it.

I am more concerned about someone see the "this only applies if you ..." and being wrong.  Or taking a SCADA system and after a couple years it's now "in the cloud." 

Our goal is to make the Internet work better.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 1 Dec 2020 16:25:02 +0100

> On 1 Dec 2020, at 16:21, Salz, Rich <rsalz=[email-masked]> wrote:
> 

There are too many people out there that break recommendations and standards without us telling them
anything. I don’t think we should encourage or assist them. We should push them forward and help 
them build better solutions and networks.

> Our goal is to make the Internet work better.

+1

/O

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 1 Dec 2020 15:36:33 +0000

> 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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 1 Dec 2020 15:51:28 +0000

>    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 <XXX> should not apply".

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 2 Dec 2020 00:10:08 +0000

> when/why <XXX> 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

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2020 10:37:32 +0000

Eliot Lear <[email-masked]> writes:

>If a device can be at all critical (and even if it isn’t), then it should be
>upgraded or replaced.

The fact that many of these devices are extremely critical is precisely why
they're never replaced or upgraded, because they can't be taken out of
production.

Peter.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Dec 2020 11:42:17 +0100

> On 2 Dec 2020, at 11:37, Peter Gutmann <[email-masked]> wrote:
> 

 I am well aware of vast amounts of insecure systems being out in the wild, up to and including pace makers.  Being critical doesn’t make them any more secure, and we shouldn’t say otherwise.  They are at risk, and we should say so, and not excuse them.

If we want to have operational guidance around how to handle insecure devices, I am ok with that.  Those might include secure facilities, application aware proxies, and other aspects, but I am not sure that is this document.

Eliot

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2020 10:44:19 +0000

STARK, BARBARA H <[email-masked]> writes:

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

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

Peter.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Dec 2020 11:54:20 +0100

> On 2 Dec 2020, at 11:44, Peter Gutmann <[email-masked]> wrote:
> 
> 
> 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

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Dec 2020 07:11:30 -0500

+1

Another problem is that "upgrades" often don't function identically to 
the firmware or equipment it would be replacing, making replacement 
inherently disruptive even if it didn't require a shutdown.

Under current conditions, relying on upgrades to fix security issues in 
industrial environments is a nonstarter.   There's a tremendous amount 
of inertia to overcome at many different levels.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2020 14:28:34 +0000

I like what Barbara wrote.

Add words that say "think if this applies to you" and publish.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 2 Dec 2020 14:58:49 +0000

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

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. 

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Eliot Lear
Sent: Wednesday, December 2, 2020 5:54 AM
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]; [email-masked]; STARK, BARBARA H <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[External email]

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

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2020 15:49:52 +0000

> it's a source of endless difficulty and

But in response to Eliot you said

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 11:00:08 -0500

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

It’s important not to catastrophize this. The IETF understands perfectly well how this process works. We write and publish RFCs, and industry (we hope!) follows. It’s a pipeline: an event happens in the IETF, it trickles out through your service providers and network product vendors, and ultimately, at some time usually quite long after the RFC is published, you have to take action.

The situation right now is that it’s been known for a long time that RC4 and MD5 are not safe to use. Your vendors have known about this for a long time. If they do not have a roll-out plan for software that corrects the problem, you have chosen the wrong vendors. Look at your agreements with them. Are they honoring them? If not, you have recourse. If you didn’t contract with them to anticipate change, it’s time to go fix that.

Stop pretending that we live in a world where we can ignore advances in technology. We don’t. If your current plans don’t assume that every bit of tech gear you have in every rack in every machine room and every hospital room will have to be upgraded at least every five years or so, hopefully in software, then change your plans now. Stop arguing with us and go do that.

Because even if browser vendors don’t follow this change quickly, you can be sure that malware writers will. Hospital after hospital keeps getting taken down with the same malware. Lives are on the line. People have died because of this.

You should be working to fix that, not trying to get us to stop asking you to fix it.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 11:03:02 -0500

> The situation right now is that it’s been known for a long time that RC4 and MD5 are not safe to use. Your vendors have known about this for a long time. If they do not have a roll-out plan for sof…

Sorry, I was talking about the wrong document. But the point is the same. If you are using TLS 1.0 or TLS 1.1, your vendors should long since have offered you an upgrade path. If they haven’t, you chose the wrong vendors. Get to work on fixing that now, rather than complaining to us. A failure to plan on your part does not constitute an emergency on our part.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 2 Dec 2020 16:19:56 +0000

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

> Cc: [email-masked]; [email-masked]; STARK,
> BARBARA H <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-
> 09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
> 
> [External email]
> 
> 
> > 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.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 2 Dec 2020 11:22:18 -0500

>they're never replaced or upgraded, because they can't be taken out of

I would like to have a few more examples of "Can't be taken out 
of production".

One I think I can address are heart pacemakers. These are 
imbedded in the patients chests. Upgrading them requires 
surgery. However, they have a limited lifespan due to their 
batteries running down, I think we're talking about 10 years or 
so, so there is a time where upgrade is practical.

Every so often, the patient needs surgery to replace the 
batteries. During this surgery, the pacemaker function is taken 
over by equipment in the operating room. The questions here are:

  How much more surgical risk is there for replacing the whole pacemaker?

If, as I suspect, the delta risk is zero, because replacing the 
battery also involves removing the old pacemaker, then battery 
replacement time is the time to perform pacemaker upgrades.

  How much risk is there in delaying upgrade to the next battery replacement?

If we think about security risk, from now-vulnerable versions of 
TLS, then risk perception will depend on the individual patient. 
Vice President Dick Cheney was famous for being very concerned 
about being attacked via his pacemaker. In his case, he might 
have very well opted for early surgery to install an upgrade. 
Most others, I suspect, would chose to run the risks, at least 
until the first real-world attacks surface.

Can anyone else work through some examples?

Cheers - Bill

-------------------------------------------------------------------------------------
Bill Frantz        | Government is not reason, it is not 
eloquence, it is force; like
408-348-7900       | a fire, a troublesome servant and a fearful 
master. Never for a
www.pwpconsult.com | moment should it be left to irresponsible 
action. Geo Washington

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 12:14:47 -0500

On Dec 2, 2020, at 11:22 AM, Bill Frantz <[email-masked]> wrote:
> One I think I can address are heart pacemakers. These are imbedded in the patients chests. Upgrading them requires surgery. However, they have a limited lifespan due to their batteries running down, I think we're talking about 10 years or so, so there is a time where upgrade is practical.

This is a perfect example of reductio ad absurdum. Not that it’s a wrong example—for this use case, I think continued use of TLS 1.0 might be a requirement, if in fact there are pacemakers that use it. However, this is a situation where a subject matter expert skilled in the art should be designing a specific approach to the problem. It is not a case where no action should be taken—quite the opposite. It is quite likely that in this situation, operational practices could be undertaken that would limit the attack surface significantly.

The point is that you can’t argue with physics. If lives depend on winning that argument, you need to stop arguing and find a different approach to protecting those lives. If peoples’ personal privacy or financial privacy depends on them, perhaps this is a slightly less serious situation, but it’s still quite important. An enterprise that fails to plan for addressing these problems should be held liable for the damage that results from that failure.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 2 Dec 2020 16:58:04 +0000

Thanks Barbara,
My responses are inline below. 

-----Original Message-----
From: STARK, BARBARA H <[email-masked]> 
Sent: Wednesday, December 2, 2020 11:20 AM
To: Ackermann, Michael <[email-masked]>; 'Eliot Lear' <lear=[email-masked]>; 'Peter Gutmann' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-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 deprecated use of these technologies inside govt networks is probably something enterprises who do business with governments can't ignore (unlike IETF RFCs).     
I ALSO AGREE (AND HOPE!!)  THAT THE US GOVT MAKING STATEMENTS ABOUT IPV6, MAY HELP GET THE ATTENTION OF ENTERPRISES.  

> 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.  
WHAT THE US GOVT DID SEVERAL YEARS AGO, DID NOT MOTIVATE MANY, IF ANY ENTERPRISES TO DEPLOY IPV6 THAT I AM AWARE OF.   It  BASICALLY GOT IPV6 INTO LIFECYCLE INITIATIVES,  WHICH IT ALREADY WAS.  THIS IS NOT USING IPV6 THOUGH. 

> 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

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.
MY CONCERN IS THAT VENDORS DEPCRECATE VERSIONS OF TLS FROM  PRODUCTS OR SERVICES, BEFORE WE ARE OPERATIONALLY READY TO SUPPORT RELATED ENVRIONMENTS.  
Barbara

> Cc: [email-masked]; [email-masked]; 
> STARK, BARBARA H <[email-masked]>; [email-masked]; [email-masked]
> > 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"
> 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.

---

From: Joe Abley <[email-masked]>
Date: Wed, 2 Dec 2020 12:24:53 -0500

Hi Bill,

On Dec 2, 2020, at 11:23, Bill Frantz <[email-masked]> wrote:

> I would like to have a few more examples of "Can't be taken out of production".
> 

I am not an expert in pacemakers, but in 2017 the US FDA found that a particular type of implanted pacemakers were vulnerable to an exploit that was considered serious enough to do something about.

https://www.fda.gov/medical-devices/safety-communications/firmware-update-address-cybersecurity-vulnerabilities-identified-abbotts-formerly-st-jude-medicals

The devices were not replaced through surgery by the manufacturer, St Jude Medical, but instead upgraded in-place using what I have seen described as an RF-based, 3-minute procedure, during which time the device operates in "backup mode". The number of deployed devices that were recommended to be upgraded was estimated by the FDA to be 465,000.

This may not be the example you are looking for.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Dec 2020 18:57:13 +0100

HI Bill,

> On 2 Dec 2020, at 17:22, Bill Frantz <[email-masked]> wrote:
> 
> Every so often, the patient needs surgery to replace the batteries. During this surgery, the pacemaker function is taken over by equipment in the operating room. The questions here are:
> 
> If, as I suspect, the delta risk is zero, because replacing the battery also involves removing the old pacemaker, then battery replacement time is the time to perform pacemaker upgrades.
> 
> If we think about security risk, from now-vulnerable versions of TLS, then risk perception will depend on the individual patient.

You should expect the NHS, FDA or equivalent to consult with manufacturers in organizations like AMI to try to characterize the risk so that doctors could have the conversation with patients.  But also it might be an area for design improvement in terms of being able to do in service upgrades.

> Vice President Dick Cheney was famous for being very concerned about being attacked via his pacemaker.

It was reported at the time that his protective detail insisted that his pacemaker not have any transceiver for fear of assassination.[1]  That was a good call because over the past several years a number of attacks on pace makers have indeed been discovered, some shockingly from remote distances.  They’re not the only such device out there, but they are an extreme example.

Eliot

[1] https://www.washingtonpost.com/news/the-switch/wp/2013/10/21/yes-terrorists-could-have-hacked-dick-cheneys-heart/

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 2 Dec 2020 18:51:37 +0000

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
 
> To: Ackermann, Michael <[email-masked]>; 'Eliot Lear'
> <lear=[email-masked]>; 'Peter Gutmann'
> <[email-masked]>
> Cc: [email-masked]' <draft-ietf-tls-oldversions-
> [email-masked]>; [email-masked]' <[email-masked]>; [email-masked]'
> <[email-masked]>; [email-masked]' <[email-masked]>
> Subject: RE: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-
> 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
> deprecated use of these technologies inside govt networks is probably
> something enterprises who do business with governments can't ignore
> (unlike IETF RFCs).
> I ALSO AGREE (AND HOPE!!)  THAT THE US GOVT MAKING STATEMENTS
> ABOUT IPV6, MAY HELP GET THE ATTENTION OF ENTERPRISES.
> 
> 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://urldefense.com/v3/__https://nvlpubs.nist.gov/nistpubs/SpecialPubl
> ications/NIST.SP.800-
> 52r2.pdf__;!!BhdT!ysE9BCIcCqyBW2t0CmGKd02gqfrj1NMAjUpr6wF3ufzEE-
> m21kyfD6OAABYxoA$
> 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.
> WHAT THE US GOVT DID SEVERAL YEARS AGO, DID NOT MOTIVATE MANY, IF
> ANY ENTERPRISES TO DEPLOY IPV6 THAT I AM AWARE OF.   It  BASICALLY GOT
> IPV6 INTO LIFECYCLE INITIATIVES,  WHICH IT ALREADY WAS.  THIS IS NOT
> USING IPV6 THOUGH.
> 
> MY CONCERN IS THAT VENDORS DEPCRECATE VERSIONS OF TLS FROM
> PRODUCTS OR SERVICES, BEFORE WE ARE OPERATIONALLY READY TO
> SUPPORT RELATED ENVRIONMENTS.
> Barbara
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 14:46:30 -0500

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

Actually, when we had this conversation in Prague in 2017 (admittedly, at the time we were talking about the TLS 1.3 transition), Michael mentioned that he’d been asking for extensions for PCI compliance in the transition to TLS 1.2. IIRC the requirements had been announced at least five years prior, although I don’t remember the precise details.

So the point is, this was something that any industry that processes credit cards has known about and had as a burning issue for much longer than 1-2 years.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 2 Dec 2020 23:00:09 +0000

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

My associated point is that Enterprises are generally not aware of this and that it is not currently on our Planning or Budget Radars.    Further, this means we are potentially years from effectively and operationally addressing such issues.     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. 

Thanks

Mike

-----Original Message-----
From: STARK, BARBARA H <[email-masked]> 
Sent: Wednesday, December 2, 2020 1:52 PM
To: Ackermann, Michael <[email-masked]>; 'Eliot Lear' <lear=[email-masked]>; 'Peter Gutmann' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[External email]

Hi Mike,

[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

> Cc: [email-masked]' 
> <draft-ietf-tls-oldversions- [email-masked]>; [email-masked]' <[email-masked]>; [email-masked]'
> > 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 
> 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).
> I ALSO AGREE (AND HOPE!!)  THAT THE US GOVT MAKING STATEMENTS ABOUT 
> IPV6, MAY HELP GET THE ATTENTION OF ENTERPRISES.
>
> > Planning or Budget radar at all, and usually takes 1-2 years (or 
> > more) to
> achieve either.
>
> 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.
> 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.
> > and on the other side Enterprises are unaware of developments at 
> > IETF
> and other
> 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.
> MY CONCERN IS THAT VENDORS DEPCRECATE VERSIONS OF TLS FROM PRODUCTS OR 
> SERVICES, BEFORE WE ARE OPERATIONALLY READY TO SUPPORT RELATED 
> ENVRIONMENTS.
> Barbara
>
> > Cc: [email-masked]; 
> > [email-masked]; STARK, BARBARA H <[email-masked]>; [email-masked]; 
> > [email-masked]
> > > 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
> > 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.
>
>

---

From: Gary Gapinski <[email-masked]>
Date: Wed, 2 Dec 2020 21:33:01 -0500

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

RFC 2119 equates, semantically, at least in English, MUST NOT with 
prohibition (_not_ deprecation).

draft-ietf-tls-oldversions-deprecate-09.txt uses MUST NOT in §4 and §5.

It does use the term "Deprecation": prominently, and likely inadvisedly, 
in §2. Re-worded, the title of §2 should be "Support for Prohibition" 
(particularly as its prior sibling is §1.2 "Terminology", which is 
inescapable boiler-plate and likely is invisible to any RFC readers).

I cannot resist citing H. L. Mencken's definition of Puritanism here.

> My associated point is that Enterprises are generally not aware of this and that it is not currently on our Planning or Budget Radars.

Perhaps such lack of awareness could be considered as the difference 
between (Aquinian) vincible and invincible ignorance.

Whether such is a mortal or venial sin, or no sin at all, could be 
considered in light of risk evaluation and management. Or one's 
tolerance for the wages of sin. Steely determination for continued use 
of flawed protocols can be admired while simultaneously lamented.

In other words, is a _prohibition_ (à la, e.g., PCI DSS) of TLS versions 
prior to TLS 1.2 (and prior to 1.3 for that matter) sufficient to demand 
upside-down crucifixion for failure to comply, or something more 
family-oriented. In either case, perhaps an appendix expressing the 
tension between prohibition and tolerance might suffice, rather than 
watering down §4 and §5. But such an appendix would be necessary in any 
normative RFC, so, in my opinion, the draft can be published without 
such an appendix.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Dec 2020 07:23:14 -0800

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

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 3 Dec 2020 17:02:37 +0000

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 ([email-masked]) ...
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.....
> 
> > My associated point is that Enterprises are generally not aware of this and
> that it is not currently on our Planning or Budget Radars.
> 
> 
> > 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.

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 3 Dec 2020 22:10:25 +0000

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 <[email-masked]> On Behalf Of STARK, BARBARA H
Sent: Thursday, December 3, 2020 12:03 PM
To: 'Watson Ladd' <[email-masked]>; 'Ackermann, Michael' <[email-masked]>
Cc: 'Peter Gutmann' <[email-masked]>; 'Eliot Lear' <lear=[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

-- 
last-call mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!BhdT!1mNyW_HOYqxvO6jkrkE01zLoel9zrEb9Om34gLPLPqvikiDKKm4gJz3zSSrsDXk$

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 3 Dec 2020 22:20:52 +0000

Sorry for the delay in responding.   Tough day at the ranch.   Just getting caught up now (or trying).  

Barbara, thanks for your response on my behalf and you are correct, I am not making any recommended content changes to the draft at all, and I am not arguing against the current text, as Watson seemed to suggest.  
I am also not suggesting that because something is inconvenient for me or other Enterprises, that the problem should not be acknowledged, as Watson stated.  In fact, it is because I will need to acknowledge and deal with related problems, that I am very interested in this topic.     And finally Watson seems to infer that I am advocating  "continuing to ignore the RFC series".    This could not be further from the truth.   Trying to get enterprises more aware of RFC developments is the primary reason I continue participate in IETF.       I strive long for a situation where enterprises are as aware, informed and compliant as possible and if their needs are factored, this becomes more achievable.  

What I actually was saying,  was a response to previous discourse in this list topic,  that was questioning why a TLS conversion might be difficult or time consuming for Enterprises, from someone on the inside of such situations.   The enterprise perspective is not usually considered or understood at IETF, and this was an attempt to highlight and attempt to encourage, the "Bridging of that gap".   My extended point was that this lack of understanding/communication, between Enterprises and IETF, is not unique to this list topic issue.   I believe this would be in the best interests of all to address and improve this, both on this topic and globally.       I want to work towards that wherever and however I can.   

Finally I agree with Barbara that those of us who may care to care to constructively address & improve the more global aspects of Enterprise/IETF interaction, should do so off this list & subject chain.        I am not aware of the "bungie jumping off the Macau Tower" aspects of the other list, so if there is a smaller and/or less painful start to this, I am all for whatever you suggest. 

Thanks

Mike

-----Original Message-----
From: STARK, BARBARA H <[email-masked]> 
Sent: Thursday, December 3, 2020 12:03 PM
To: 'Watson Ladd' <[email-masked]>; Ackermann, Michael <[email-masked]>
Cc: 'Eliot Lear' <lear=[email-masked]>; 'Peter Gutmann' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[External email]

> for any related confusion regarding IPv6, even though, for the 
> purposes of my comment, they are similar.
> >
> >
> essentially that prior versions of TLS may be considered insecure, 
> etc.  and should be deprecated.....
>
> >    And we must do so in conjunction with Partners, Clouds, Clients 
> > and
> others.
> > And finally, this may not be a gap that the IETF should care about 
> > or
> address, but someone should, IMHO.
>

---

From: Rob Sayre <[email-masked]>
Date: Thu, 3 Dec 2020 15:53:10 -0800

On Thu, Dec 3, 2020 at 2:38 PM Ackermann, Michael <[email-masked]>
wrote:

> The enterprise perspective is not usually considered or understood at IETF
>

I think that perspective is both considered and understood, but not usually
accommodated.

I can't even imagine shipping TLS 1.2 for anything at this point, and I
don't think the IETF should be publishing new documents that make
allowances for TLS versions previous to 1.3.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2020 00:54:25 +0000

(Even though this sub-thread has no effect on the draft, I
couldn't resist:-)

> I think that perspective is both considered and understood, but not usually

I think you're both wrong:-)

It seems wrong to me to assume that there is a singular
and united "enterprise perspective" on TLS and that was
very clear from earlier debates where some people made
one kind of assertion, while others, also correctly saying
they represented "enterprises" fully disagreed.

There are of course a set of networks that have difficulty
in managing and updating the systems that make up their
networks. There are others for whom updating TLS is going
to be much less of an issue due to the nature of those
networks (newer, or more automated/centralised, or whatever).
Both situations arise for understandable valid reasons but
dealing with the cases where problems do or don't arise
isn't helped IMO by over-claiming on any side.

And yes, in addition to the above, there are people whose
main (and also reasonable) concern is the web, and their
concerns and ability to handle updates do differ. And
there are others for whom other issues take precedence.

None of that means a lack of consideration, nor a lack
of accommodation. For things like TLS, where code is
often delivered via libraries, the timing of change does
sometimes make for awkward compromises, that will make
some of the above unhappy, but that's just life and is
why the WG chairs and ADs are such well paid consensus
callers:-)

I think the IETF process works pretty well for all this,
overall, and over time.

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 3 Dec 2020 17:03:11 -0800

On Thu, Dec 3, 2020 at 4:54 PM Stephen Farrell <[email-masked]>
wrote:

> networks.

That's true, but attackers run on their own schedule.

I don't think IETF documents should include caveats for older TLS versions
that are quite obviously flawed.

thanks,
Rob

---

From: Ben Smyth <[email-masked]>
Date: Tue, 1 Dec 2020 06:52:12 +0100

I haven't followed all the nuances of this discussion, but it seems to boil
down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private
enterprise running legacy kit, which makes decision makers anxious, since
they don't want responsibility for something they "MUST NOT" do: A solution
might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby
allowing sectors to define their standards/principles/expectations.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 4 Dec 2020 03:30:23 +0000

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 <[email-masked]>
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H <[email-masked]>; 'Watson Ladd' <[email-masked]>; Ackermann, Michael <[email-masked]>
Cc: 'Peter Gutmann' <[email-masked]>; 'Eliot Lear' <lear=[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
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]

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:

-----Original Message-----

From: last-call <[email-masked]<mailto:[email-masked]>> On Behalf Of STARK, BARBARA H

To: 'Watson Ladd' <[email-masked]<mailto:[email-masked]>>; 'Ackermann, Michael' <[email-masked]<mailto:[email-masked]>>

Cc: 'Peter Gutmann' <[email-masked]<mailto:[email-masked]>>; 'Eliot Lear' <lear=[email-masked]<mailto:lear=[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>

I'll see what happens if I start a thread over there ([email-masked]<mailto:[email-masked]>) ...

Barbara

> > And I think I was aware of all you state below regarding TLS, and

> > apologize

> > My associated point is that Enterprises are generally not aware of

> > this and

> > Further, this means we are potentially years from effectively and

> operationally addressing such issues.

> > And my general, overall point is that the answer to addressing the

> > above is

--

last-call mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Rob Sayre <[email-masked]>
Date: Thu, 3 Dec 2020 21:32:27 -0800

Hi,

What is the definition of “enterprise”?

Thanks,
Rob

On Thu, Dec 3, 2020 at 7:48 PM Ackermann, Michael <[email-masked]>
wrote:

> 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 😊
>
>
>
> To: STARK, BARBARA H <[email-masked]>; 'Watson Ladd' <
> [email-masked]>; Ackermann, Michael <[email-masked]>
> Cc: 'Peter Gutmann' <[email-masked]>; 'Eliot Lear' <lear=
> [email-masked]>; [email-masked]' <[email-masked]>; '
> [email-masked]' <[email-masked]>; '
> [email-masked]' <
> [email-masked]>; [email-masked]' <
> [email-masked]>
> 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]
>
>
>
>
>
> 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:
>
>
> 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:
>
>
> Cc: 'Peter Gutmann' <[email-masked]>; 'Eliot Lear' <
> lear=[email-masked]>; [email-masked]' <[email-masked]>;
> [email-masked]' <[email-masked]>; '
> [email-masked]' <
> [email-masked]>; [email-masked]' <
> [email-masked]>
>
> Subject: Re: [Last-Call] [TLS] Last Call:
> <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and
> TLSv1.1) to Best Current Practice
>
>
>
> 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. ?
>
>
>
> [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.
>
> <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.
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 4 Dec 2020 14:19:39 +0000

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 <[email-masked]>
Sent: Friday, December 4, 2020 12:33 AM
To: Ackermann, Michael
Cc: BRUNGARD, DEBORAH A; Eliot Lear; Peter Gutmann; STARK, BARBARA H; Watson Ladd; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi,

Thanks,
Rob

On Thu, Dec 3, 2020 at 7:48 PM Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:

Deborah

Mike

-----Original Message-----
From: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; 'Watson Ladd' <[email-masked]<mailto:[email-masked]>>; Ackermann, Michael <[email-masked]<mailto:[email-masked]>>
Cc: 'Peter Gutmann' <[email-masked]<mailto:[email-masked]>>; 'Eliot Lear' <lear=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
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]

https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/<https://urldefense.com/v3/__https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/__;!!BhdT!zmG3F1slksg8AtkdGf3Lkkb9Lpbn1ePVRYSyQggUh92yK8Xb7tvzVDr-EG6n_mk$>

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<https://urldefense.com/v3/__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__;JSUlJSM!!BhdT!zmG3F1slksg8AtkdGf3Lkkb9Lpbn1ePVRYSyQggUh92yK8Xb7tvzVDr-fyEbAVg$>

-----Original Message-----

Cc: 'Peter Gutmann' <[email-masked]<mailto:[email-masked]>>; 'Eliot Lear' <lear=[email-masked]<mailto:lear=[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

Barbara

--

last-call mailing list

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!BhdT!zmG3F1slksg8AtkdGf3Lkkb9Lpbn1ePVRYSyQggUh92yK8Xb7tvzVDr-iB4nfYQ$>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2020 15:21:55 +0000

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

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 4 Dec 2020 15:14:21 +0000

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 <[email-masked]>
Sent: Friday, December 4, 2020 9:20 AM
To: Rob Sayre <[email-masked]>; Ackermann, Michael <[email-masked]>
Cc: Eliot Lear <lear=[email-masked]>; Peter Gutmann <[email-masked]>; STARK, BARBARA H <[email-masked]>; Watson Ladd <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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]

Deborah

________________________________
From: Rob Sayre <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 4, 2020 12:33 AM
To: Ackermann, Michael
Cc: BRUNGARD, DEBORAH A; Eliot Lear; Peter Gutmann; STARK, BARBARA H; Watson Ladd; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi,

Thanks,
Rob

Deborah

Mike

-----Original Message-----
From: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; 'Watson Ladd' <[email-masked]<mailto:[email-masked]>>; Ackermann, Michael <[email-masked]<mailto:[email-masked]>>
Cc: 'Peter Gutmann' <[email-masked]<mailto:[email-masked]>>; 'Eliot Lear' <lear=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
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]

https://www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/<https://urldefense.com/v3/__https:/www.internetsociety.org/blog/2014/10/new-rfc-7381-enterprise-ipv6-deployment-guidelines/__;!!BhdT!zmG3F1slksg8AtkdGf3Lkkb9Lpbn1ePVRYSyQggUh92yK8Xb7tvzVDr-EG6n_mk$>

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<https://urldefense.com/v3/__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__;JSUlJSM!!BhdT!zmG3F1slksg8AtkdGf3Lkkb9Lpbn1ePVRYSyQggUh92yK8Xb7tvzVDr-fyEbAVg$>

-----Original Message-----

Barbara

--

last-call mailing list

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/last-call__;!!BhdT!zmG3F1slksg8AtkdGf3Lkkb9Lpbn1ePVRYSyQggUh92yK8Xb7tvzVDr-iB4nfYQ$>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 4 Dec 2020 15:41:07 +0000

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 <[email-masked]> 
Sent: Friday, December 4, 2020 10:22 AM
To: Ackermann, Michael <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; Rob Sayre <[email-masked]>
Cc: Eliot Lear <lear=[email-masked]>; Peter Gutmann <[email-masked]>; STARK, BARBARA H <[email-masked]>; Watson Ladd <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (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,

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

> front in the process (perhaps even making positive contributions OMG),  
> rather than only whining about deployment/operational issues

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 12:20:35 -0500

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.

---

From: tom petch <[email-masked]>
Date: Fri, 4 Dec 2020 17:32:56 +0000

> 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

>> [email-masked]' <[email-masked]>;'

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Dec 2020 18:57:21 +0100

[Reducing a bit]

Ted,

Thanks for this note.  I think actually there is something the IETF can do, and this is the part of the discussion I like.  Here are a few examples:

Blog that this is coming, and talk a little about the implications.
Write an operational guide to handling these sorts of changes.

On that latter bullet, Fred and I did that early on with IPv6 to talk a little about renumbering in that environment.  It wasn’t meant as a standard, but just guidance.  Here we could say a few things:
Understanding some of the issues:
Some devices don’t speak > 1.1; some devices don’t speak < 1.2
Only a problem if they have to interact
What log messages to look for when there is a problem.
Special considerations for customer-facing services
Warn customers
Load balancer issues
Debugging changes
Anomaly detection changes (if any)
Having an inventory of devices that are on one’s network is a good thing.
Knowing which of those devices is using TLS 1.0/1.1 is important.
Here’s how to detect version information, perhaps with Wireshark, tcpdump, etc.
Options for devices:
Upgrade plan
Obsolescence
Front end proxy

Now it is possible that this is a document that should go to LISA or some place like that, but it doesn’t seem like a bad BCP, if there is interest.

Eliot

> On 4 Dec 2020, at 18:20, Ted Lemon <[email-masked]> wrote:
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 4 Dec 2020 10:09:25 -0800

A document like that seems difficult to object to, but it’s perhaps a bit
late. For example, see:
https://twitter.com/isoc_insights/status/1334189350481850370?s=21

Thanks,
Rob

On Fri, Dec 4, 2020 at 9:59 AM Eliot Lear <lear=[email-masked]>
wrote:

> [Reducing a bit]
>
> Ted,
>
> Thanks for this note.  I think actually there *is* something the IETF can
> do, and this is the part of the discussion I like.  Here are a few examples:
>
>
>    - Blog that this is coming, and talk a little about the implications.
>    - Write an operational guide to handling these sorts of changes.
>
>
> On that latter bullet, Fred and I did that early on with IPv6 to talk a
> little about renumbering in that environment.  It wasn’t meant as a
> standard, but just guidance.  Here we could say a few things:
>
>    - Understanding some of the issues:
>       - Some devices don’t speak > 1.1; some devices don’t speak < 1.2
>       - Only a problem if they have to interact
>    - What log messages to look for when there is a problem.
>    - Special considerations for customer-facing services
>       - Warn customers
>       - Load balancer issues
>       - Debugging changes
>       - Anomaly detection changes (if any)
>    - Having an inventory of devices that are on one’s network is a good
>    thing.
>    - Knowing which of those devices is using TLS 1.0/1.1 is important.
>    - Here’s how to detect version information, perhaps with Wireshark,
>    tcpdump, etc.
>    - Options for devices:
>       - Upgrade plan
>       - Obsolescence
>       - Front end proxy
>
>
> Now it is possible that this is a document that should go to LISA or some
> place like that, but it doesn’t seem like a bad BCP, if there is interest.
>
> Eliot
>
> 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.
>
>
> --
> last-call mailing list
> [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Dec 2020 19:32:34 +0100

Well I hope that’s right, but there’s reason for doubt.  There are indeed quite a lot of old devices that sit around and don’t generate a lot of traffic.  Consider this too: that data you’re showing is from Mozilla, and so they have a singular web vantage point.  That’s significant, to be sure.  But keep in mind that this draft touches a great many more protocols.

Eliot

> On 4 Dec 2020, at 19:09, Rob Sayre <[email-masked]> wrote:
> 
> A document like that seems difficult to object to, but it’s perhaps a bit late. For example, see:
> https://twitter.com/isoc_insights/status/1334189350481850370?s=21 <https://twitter.com/isoc_insights/status/1334189350481850370?s=21>
> 
> Thanks,
> Rob
> 
> On Fri, Dec 4, 2020 at 9:59 AM Eliot Lear <lear=[email-masked] <mailto:[email-masked]>> wrote:
> [Reducing a bit]
> 
> Ted,
> 
>> On 4 Dec 2020, at 18:20, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 13:49:29 -0500

> Now it is possible that this is a document that should go to LISA or some place like that, but it doesn’t seem like a bad BCP, if there is interest.

To be clear, it has felt like Michael is arguing that we shouldn’t deprecate TLS 1.1, or maybe that we should have communicated this better and earlier. The first goal seems perhaps to have evolved into the second, and that’s good news. Perhaps I was wrong in thinking that the first position was ever the goal, but that’s how I read it, and was the point I was speaking to.

If we agree with the second interpretation of Michael’s point, then what you are proposing would certainly be what we should have done better and earlier, but might as well do now.

That said, this is an unsolvable problem if enterprises continue to operate under the assumption that it is ever okay to purchase any device or service that doesn’t have a clearly defined upgrade path. This is the operational practice that I don’t think IETF is competent to address. Regulations and enforcement would help. Having worked at a bank in the past, I know what FDIC audits look like. Enterprise generally tries to avoid audits of this sort, but they can be fairly effective, at least from a network security perspective. The point being, this is something that a functioning government, if such a thing yet exists in this world, could do to improve the situation going forward. I would argue that as individuals, we should be doing what we can to communicate to our elected representatives (if we live in a functioning democracy) that this is necessary.

What you are proposing is a document about what to do given the situation we have sleepwalked into. I think that’s good too. This is something that the IETF could conceivably do, although some of your action items above (e.g. what log messages to look for) sound impossible. Still, I would not object to doing this work in v6ops if there’s energy for it; not sure how much I’d have to contribute that someone else wouldn’t be more qualified to contribute.

But the bottom line is that deprecating TLS 1.0 and 1.1 is the right thing to do, and now is a better time to do it than now+x, for all positive values of x. None of what we are discussing in terms of mitigation strategies changes that in any way.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 4 Dec 2020 20:00:07 +0000

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 <[email-masked]> 
Sent: Friday, December 4, 2020 12:21 PM
To: Ackermann, Michael <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; Rob Sayre <[email-masked]>; Peter Gutmann <[email-masked]>; Watson Ladd <[email-masked]>; Eliot Lear <lear=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; STARK, BARBARA H <[email-masked]>; [email-masked]
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]

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.

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.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 15:11:17 -0500

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

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

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

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

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.

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

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?

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 4 Dec 2020 22:04:17 +0000

Elliot

Quite a bit of what you say would be helpful.

Enterprises are in need of a lot of assistance and information on many topics and will take help wherever we can get it.   And BTW, if you think we are slow on TLS versions,  then please do not even ask about IPv6 😊.

So I think there would be interest in all that you talk about below,  but the biggest areas of concern, IMHO might be:

  *   Finding out how much TLS 1.0, 1.2 and 1.3 is on our networks today.   And Sadly, we will likely find old versions of SSL as well.
  *   Determining which devices, OS’s,  or software products are capable of which versions of TLS.   And what related upgrade paths exist (if any are available).
  *   How changes will affect network management/monitoring.  (which I think is what you meant by Debugging, which is an important subset).

I think you are suggesting similar things below and more, which gives me a great feel that you understand the issues we will face and on many issues, how to address them.   Thanks so much for that!

I think there would be great interest in something like this, but in terms of how to deliver, I am not aware of what LISA is?

Thanks again!

Mike

From: Eliot Lear <[email-masked]>
Sent: Friday, December 4, 2020 12:57 PM
To: Ted Lemon <[email-masked]>
Cc: Ackermann, Michael <[email-masked]>; [email-masked]
Subject: Next steps on Deprecation/Obsolescence of TLS 1.0/1.1 Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Reducing a bit]

Ted,

  *   Blog that this is coming, and talk a little about the implications.
  *   Write an operational guide to handling these sorts of changes.

  *   Understanding some of the issues:

     *   Some devices don’t speak > 1.1; some devices don’t speak < 1.2
     *   Only a problem if they have to interact

  *   What log messages to look for when there is a problem.
  *   Special considerations for customer-facing services

     *   Warn customers
     *   Load balancer issues
     *   Debugging changes
     *   Anomaly detection changes (if any)

  *   Having an inventory of devices that are on one’s network is a good thing.
  *   Knowing which of those devices is using TLS 1.0/1.1 is important.
  *   Here’s how to detect version information, perhaps with Wireshark, tcpdump, etc.
  *   Options for devices:

     *   Upgrade plan
     *   Obsolescence
     *   Front end proxy

Eliot

On 4 Dec 2020, at 18:20, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Dec 2020 14:05:35 -0800

On Fri, Dec 4, 2020 at 10:33 AM Eliot Lear <lear=[email-masked]>
wrote:

> Well I hope that’s right, but there’s reason for doubt.
>

This question has actually been extensively studied. For instance:

Holz et al. measured the deployment of TLS 1.3 using both surveys
and passive measurements from 2012-2019.
https://arxiv.org/pdf/1907.12762.pdf

Kotzias et al. meausred the deployment of TLS versions and
cipher suites in using both Censys and passive scans from
2012-2018

Qualys does regular surveys of TLS servers (on the Web) to see
what they support.
https://www.ssllabs.com/ssl-pulse/

The general story is the same: there is increasing but far from
universal support for TLS 1.3 and nearly universal TLS 1.2
support. For instance Qualys shows 99% of Web sites
supporting TLS 1.2 and the vast majority of measured connections
look like they are 1.2 or above (eyeballing at a percent or two)

-Ekr

Thanks,
Rob

--

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 4 Dec 2020 22:29:22 +0000

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 <[email-masked]> 
Sent: Friday, December 4, 2020 3:11 PM
To: Ackermann, Michael <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; Rob Sayre <[email-masked]>; Peter Gutmann <[email-masked]>; Watson Ladd <[email-masked]>; Eliot Lear <lear=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; STARK, BARBARA H <[email-masked]>; [email-masked]
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]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 17:47:54 -0500

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

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.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 4 Dec 2020 23:53:48 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 20:32:46 -0500

On Dec 4, 2020, at 19:17, Nick Hilliard <[email-masked]> 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.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 4 Dec 2020 17:46:06 -0800

> 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

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 5 Dec 2020 11:05:22 +0000

Ted Lemon wrote on 05/12/2020 01:32:
> 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.
yip, this is one of the reasons that medical and other certified 
equipment (e.g. military, industrial, etc) is so expensive to start 
with: there's an expectation of long life and an understanding that this 
is reflected in either the up-front cost or ongoing support / 
maintenance costs.  For the bulk-produced consumer-oriented product 
market, people are not prepared to pay and in any event it's usually 
cheaper to replace equipment than repair or maintain properly - and 
that's even if the product is still relevant.  Who still uses their USR 
Sportster?  Or even their 802.11b wifi access point?  In 10 years time, 
there will be

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

This is only part of a much larger issue relating to the speed of 
technical innovation and separately, consumerism.

What's relevant to the IETF is that it needs to make sound technical 
recommendations about the usability and appropriateness of standards. 
If organisations choose not to keep supporting some or all of their 
product lines, this shouldn't impact the IETF's ability to do its job.

Nick

---

From: Christian de Larrinaga <[email-masked]>
Date: Sat, 05 Dec 2020 11:50:01 +0000

> product lines, this shouldn't impact the IETF's ability to do its job.

However governments are busy writing up standards for managing the
secure  deployment of devices. The UK's DCMS has been working on this for a couple  of years

The local ISOC chapter has been engaging on this. On that count IETF
participants might like to keep engaged with those ISOC chapter
liaisons? Who I'm sure would be grateful for informed input as well. 

As a general observation the issue of vendors falling away from
supporting  devices is at odds with the promoted market model of
licensing IPR and maintaining restrictions over IPR after support falls
away.

Unless that IPR becomes public domain - or opened at least in regards
the scope of empowering the right to repair etc.

The practicalities of that is something IETF can think through as part
of its IPR policies?

Another observation is that manufacturer/vendors who force updates on
their  devices will tend to consider their own devices not others which
in context of "IoT" are very likely to also be interoperating from other vendors
or FOSS / hardware. That creates space for lots of stools for security to fall between. 

The issues around interoperability also means serving the responsibility
of user administrators across whatever pool of vendors or FOSS supply chains they choose to
deploy and commission support. Depending entirely on each vendor you use
has never been a good idea if you want a functional system.

So specifications to serve interoperability in terms of securing real world
installations of devices running from a selection of IETF defined
protocols is something IETF can think about too?

For discussion? I would expect that thinking to not assume "vendor" lock in but empower user
administrated support in concert with vendor support (if chosen (not
imposed)) as long as that is available and faciitate open alternatives particularly when that falls away.

This also seems a point where IETF specifications can offer
guidance. 

C
-- 
Christian de Larrinaga

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 5 Dec 2020 14:43:01 +0000

>  Consider this too: that data you’re showing is from Mozilla, and so they have a singular web vantage point.

Here’s the vantage from Akamai, which is also a singular viewpoint, but our customers tend to be big enterprises:

TLS 1.0 and 1.1 is 1/1000 of the traffic of TLS 1.2 and 1.3

Note that this *DOES NOT* count traffic inside the corporate firewall, obviously, which is where I think the “enterprise and TLS” issue comes up.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 6 Dec 2020 07:59:02 -0500

Having risk management experience as well as policy establishment and enforcement, I would rather see the clear notification that something is not secure.  Then the organization makes the decision to take that risk based on likelihood/impact considerations.  This factors in risk tolerance and business objectives.  I am an author on the draft, and don’t think this is the place for those business decisions to be made.

Best regards,
Kathleen 

Sent from my mobile device

> On Dec 1, 2020, at 12:52 AM, Ben Smyth <[email-masked]> wrote:
> 
> 
> I haven't followed all the nuances of this discussion, but it seems to boil down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private enterprise running legacy kit, which makes decision makers anxious, since they don't want responsibility for something they "MUST NOT" do: A solution might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby allowing sectors to define their standards/principles/expectations. 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 6 Dec 2020 08:01:26 -0500

I disagree here as those other implementations just need to make their own business risk decisions and put in place an exception process.  One option in the risk decision process is to accept risk, you can also mitigate, eliminate, or transfer the risk.

Best regards,
Kathleen 

> On Dec 1, 2020, at 7:57 AM, Keith Moore <[email-masked]> wrote:
> 
> Not specifically relevant to this draft, but:  Is it actually defined anywhere that IETF standards only apply to the public Internet?  IMO IETF needs to realize that implementations of its standards are used outside of the public Internet and consider that when writing its documents.  (even though different rules may be appropriate on private and mostly-isolated networks)
> 
> Keith
> 
> p.s. I keep thinking that this "MUST NOT TLS < 1.2" recommendation is like a public health recommendation, one that is worded over-simply to try to make it have maximum useful effect but perhaps to the point of being misleading or even harmful. e.g. "You MUST wear masks to reduce the spread of COVID-19", but not saying "oh yeah, if you're outdoors and not around other people you're probably fine without a mask" and "masks are pointless if you only wear them over your mouths or chins", and "the masks that have valves in them to allow exhaled breath to exit unimpeded are also useless for this purpose" and "you need to wear them when indoors and around co-workers, not merely when customers or visitors are present".  At least where I live I see so many people using masks in ineffective ways that I don't think the simple recommendation is working, though I'm not sure that a more detailed recommendation would work better.
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 6 Dec 2020 08:23:51 -0500

FYI - I did present this in Montreal to the enterprise group Nalini runs a few years ago to make sure they had a heads up and a place where questions could be asked freely.  They did come to the mic in support at the TLS session that week.  Yes, it’s disruptive, but TLSv1.2 is still supported and they have risk management processes in place to deal with exceptions.

I put a lot of thought into how we can move forward with encryption.  It resulted in this book that is a 5-10 year look ahead in terms of how can we embrace E2E, including on enterprise networks.  There are several things that need to happen first and industry work has begun to help on it.  The end point needs to be more secure.  DevSecOps, granular security, and a shift towards managing at the end point are among the changes in play.

Transforming Information Security: Optimizing Five Concurrent Trends to Reduce Resource Drain https://www.amazon.com/dp/1839099313/ref=cm_sw_r_cp_api_glc_fabc_VJnZFb0DJZCH1

I’m happy to write a blog as Eliot suggested and I’ll keep it focused as requested, but do want people to see some of the long term options.

Best regards,
Kathleen 

> On Dec 4, 2020, at 1:50 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Dec 2020 21:07:58 -0500

EXECSUM: publish. We waited too long for this.

    > look like they are 1.2 or above (eyeballing at a percent or two)

That's totally public web centric.

I read somewhere that a significant portion of TLS traffic is b2b, and
doesn't show up as "web sites".  I'm sorry, I don't have a reference, I'd
have to dig through bookmarks for a few hours.

This survey can't measure the thousands of devices that are stuck at TLS 1.0,
because the vendor's abandonned ("EOL") them in 2016 without releasing anything
significant since 2010.

For instance, two entire generations of "managed" SOHO 10/100/1000 switches.
Still perfectly serviceable.... until the browser interface fails because the
browsers decide, based upon the above survey to move on.

It's a lot of eWaste.
I specifically paid top-dollar for a device that I thought would get support
from a reputable vendor.  I installed a certificate into the device, and
bought into HTTPS everywhere, but I feel betrayed.
I feel that I should have instead planned differently.

But:
1) I'm totally in favour of this document.

2) I wish it had been done five years ago so that the vendors might have done an
   upgraded before the product was abandonned.
   Let's not wait so long again.  Let's put a deadline on TLS 1.2 support.

3) I come back to my claim that we need some kind of "iot-browser", which has a
   significantly different policy, and which is unable to talk to facebook,
   or banks.
   It would be interesting to figure out what the limitations we need to do are.

Eliot started a thread on IOTOPS about this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Dec 2020 04:44:10 -0800

> browsers decide, based upon the above survey to move on.

We didn't make our decisions based on this survey. We based them on our own
measurements of how much TLS traffic < 1.2 we were seeing, which also
includes
the non-public Web. If you look upthread you'll see Eliot complaining that
that's
too Firefox centric, so I provided the papers listed above.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Dec 2020 07:59:23 -0500

One question that I think makes sense to ask is, odd this the right metric?  Eliot suggested that maybe what we mean by obsolete is that orgs should start phasing it out, not that they are done phasing it out. I think I agree. 

> On Dec 7, 2020, at 07:45, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Sun, Dec 6, 2020 at 6:08 PM Michael Richardson <[email-masked]> wrote:
>> 
> measurements of how much TLS traffic < 1.2 we were seeing, which also includes
> the non-public Web. If you look upthread you'll see Eliot complaining that that's

---

From: Eliot Lear <[email-masked]>
Date: Mon, 7 Dec 2020 15:54:50 +0100

> On 7 Dec 2020, at 13:59, Ted Lemon <[email-masked]> wrote:
> 

More or less.  The question is this: when do we believe that a technology is no longer appropriate to deploy?  TLS 1.0 and 1.1 are obvious.  What’s the trigger point for TLS 1.2 or for that matter, TCP?

Eliot

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 7 Dec 2020 15:39:42 +0000

> On 7 Dec 2020, at 14:54, Eliot Lear <lear=[email-masked]> wrote:
> 
> when do we believe that a technology is no longer appropriate to deploy?

The answer is normally: when the financial cost of continuing the deployment (including the cost of the risk) exceeds the expected financial reward of continuing the deployment. 

- Stewart

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Dec 2020 11:34:51 -0500

> The answer is normally: when the financial cost of continuing the deployment (including the cost of the risk) exceeds the expected financial reward of continuing the deployment. 

The actual time that will result from this calculation depends on whose costs are being accounted for. If the owner of the equipment is able to externalize some costs (e.g. by passing the risk on to the customer), or by landfilling old units rather than paying to have them recycled, then this approach alone may not produce a result that is optimal for all participants.

---

From: Christian de Larrinaga <[email-masked]>
Date: Mon, 07 Dec 2020 16:52:29 +0000

> The answer is normally: when the financial cost of continuing the deployment (including the cost of the risk) exceeds the expected financial reward of continuing the deployment. 

but whose risk, whose cost?

C

-- 
Christian de Larrinaga

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Dec 2020 13:31:56 -0500

On Mon, Dec 7, 2020 at 9:55 AM Eliot Lear <lear=[email-masked]>
wrote:

> > One question that I think makes sense to ask is, odd this the right
> metric?  Eliot suggested that maybe what we mean by obsolete is that orgs
> should start phasing it out, not that they are done phasing it out. I think
> I agree.
>
> More or less.  The question is this: when do we believe that a technology
> is no longer appropriate to deploy?  TLS 1.0 and 1.1 are obvious.  What’s
> the trigger point for TLS 1.2 or for that matter, TCP?
>

When we deprecate, then vendors and libraries set end of support dates.  We
obsolete when a new version is released, so TLSv1.2 has been obsoleted, but
not deprecated.  TLSv1.0 and TLSv1.1 have been obsoleted and are in process
of being deprecated.   OpenSSL had stated they would continue to support
library versions published for 5 years from publication date.  This means
that whatever the publication date was/is of a release that had the
deprecated versions, support would continue to allow for a reasonable
transition period.

Does that help?

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Eliot Lear <[email-masked]>
Date: Sat, 5 Dec 2020 10:57:44 +0100

[moving to iotops and arch-discuss, as we are now leaving the topic of LC]

Ted,

I’m going to pick on you a bit here, but just to call out a larger point, because… we are almost nowhere on this problem.

> On 4 Dec 2020, at 23:47, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 

That premise is a bit too sweeping. Stuff doesn’t get upgraded for a myriad of reasons.  One is that stuff gets old.  Every manufacturer has this problem.  Cisco hardware is built to last, and it is not surprising to find equipment in the secondary market that is 15-20 years old.  If you look at a workhorse like a 7200 router that they (I wasn’t at Cisco yet) introduced in 1996, stopped selling in 2012, and only last year stopped issuing software patches for, you can still find equipment on the secondary market.  “Works like new”, $1,200 plus shipping[1].   In that span of time, just how many iPhones and Android systems have come and gone?*  What sort of eWaste problem has been created?  How long should DLink provide security updates for that frisbee that connects you to the world?  5 years? 10 years? 15 years?  Singapore didn’t answer that question, as I understand it.

And that’s in the IT market.  Now go look at the thermostat in your house.  How old is it?  In most cases, it dates back to when a house was built.  That’s the sign of a good product.  In some cases, the manufacturer may have gone out of business.    How long should an auto manufacturer support a car?  I will tell you that in general it is less than the length of time we support a router, and in some cases far less.  There are manufacturing presses that date back to the first use of electricity.  You think we have problems now?  Just wait a few years.

And then there is when and how to perform upgrades.  Apple along with a great many consumer providers has it easy when it comes to device upgrades: they can force the requirement that upgrades occur over the Internet, and that the device be rebooted.  Now try that with a transformer providing power to a hospital or a controller for an oil derrick in Alaska, where the duty cycle of a device can easily be 40 years, and the maintenance window is… oh wait.  There isn’t one.  Clearly these devices need to support in service upgrades, but even those have to be carefully thought out, tested, and planned.  And if something goes wrong, well...

My point isn’t that these upgrades shouldn’t occur.  But we do need to think differently about the whole life cycle of a system.  I’m far from the first to talk about this, nor is this insight particularly recent.  Dan Geer wrote as far back as 2012 about creating Internet kill switches[2,3].  Nor is this problem related only to security.  I’ve already mentioned the tension between security and eWaste. Cloud computing offers tremendous efficiencies, both economic and environmental, by shifting intelligence from dedicating computing to shared.  But think about what just happened this year: a number of manufacturers who use the cloud failed.  What happened to their products?  And of course Cloud computing by definition assumes Internet access, which the OT world is only beginning to allow.  After Amazon’s and Microsoft’s outages over the last several months, they may be a bit less interested.

Boiling this down, it seems to me IOT lifecycle, support models, and security models, including software ownership, open source, associated complexities, is a worthy topic to be picked up and discussed in iotops, given the life spans of some of these devices.

In answer to your direct question: yes we should be deprecating broken protocols faster than we have been.  The LC in question should have occurred at least five years ago, and it will more than justify the challenge it will give the RPC when they go to create the Updates: header ;-)

Eliot

* And don’t even get me started on Android and the vast technical deficit it and manufacturers created.  The absolutely naive and self-serving argument that only the h/w manufacturers are responsible for that mess demonstrates the limits of OSS.

[1] https://www.ebay.com/p/54829831 <https://www.ebay.com/p/54829831>
[2] https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf <https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf>
[3] https://queue.acm.org/detail.cfm?id=2479677 <https://queue.acm.org/detail.cfm?id=2479677>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2020 17:27:21 -0500

> The answer is normally: when the financial cost of continuing the
    > deployment (including the cost of the risk) exceeds the expected
    > financial reward of continuing the deployment.

The financial cost for whom?
If I have to rip equipment out of my walls, that's a serious cost to me.

When Google/Nest discontinued Revolv in 2016, for instance, the eventual
lawsuit resulted in them refunding everyone's money.
So, the reward was 100% loss of revenue, except that it got them acquired.
Everyone lost, except the VCs.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 7 Dec 2020 17:23:50 -0800

> the trigger point for TLS 1.2 or for that matter, TCP?

TLS 1.2 has been superseded. I don't think the IETF should be in the
business of reassuring people their older TLS deployments are ok. They
probably aren't.

thanks,
Rob

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 8 Dec 2020 11:35:10 +0000

>I would like to have a few more examples of "Can't be taken out of

Well as a bit of a generalisation anything running an RTOS is likely to be
something that can't be taken out of production, and certainly wouldn't be
taken out of production for something as minor as a security changeover.
These are devices for which availability overrides all other concerns.  To
give an actual example from earlier this year, a risk analysis for a set of
devices included a discussion of how long and under what conditions you could
keep operating a device after it had been compromised by an attacker, because
the only thing worse than a device that was co-managed by an attacker would be
a device that wasn't functioning at all.  The presence of an attacker, while
suboptimal, was still far better than not having it operational at all.

Some examples of reasons why devices can't be easily upgraded include one I
mentioned a year or two back on this list for which the upgrade cycle, which
required a site visit for each device, ran over about ten years and the next
cycle was planned to complete in 2030 (but these things always take longer
than planned, I don't think they've even started it), and for more exotic
examples, "service calls to low earth orbit are expensive", "we can only
replace the hardware when the reactors are shut down for refuelling", and
"[suggested change] is a good idea but would involve renegotiating
international treaties", which still rates as the most solid reason-we-can't-
do-it I've ever heard.

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Dec 2020 06:56:53 -0800

Hi all,

Thank you for the robust discussion on this last-call thread (just a bit past
100 messages so far), including the interesting discussion (though arguably a
tangent to the document at hand by the end) about how the IETF can better
provide operational guidance and support robust and sustainable device
ecosystems and lifecycles.  While extended implementation guidance seems out
of scope for this document, reference(s) to such guidance elsewhere may be
useful, if the appropriate material to reference is located.

Though there were some relatively minor issues reported (Tom Petch noted a
botched reference or two, the gen-art and ops-dir reviews found some nits, and
John Klensin advocated for greater clarity on the relationship between RFC
5469 and RFC 5246), the bulk of the discussion focused on the potential harm
that would be caused by an immediate and universal move to TLS 1.2 as the
minimum version of TLS used at runtime or the removal of support for older TLS
versions from major software implementations such as TLS libraries or
browsers.

We heard about many classes of deployed systems that are in practice not
upgradeable (including due to the risk of breakage introduced by the update
process), and the knock-on effects on the local ecosystems that contain such
devices, including both where there are old TLS clients and where there are
old TLS servers, and a desire to have more text to acknowledge these use cases
and potentially indicate workarounds for them.  Many of these facts were
known to and considered by the WG at the decision to go forward with this
document around the time of IETF 102 (the benefits to the ecosystem were
deemed to outweight the breakage that would be incurred), but hearing it
again (and all in one place) is still useful.

We were also reminded that not only does the TLS ecosystem extend beyond the
Web, it also extends even to systems not connected to the Internet and
divorced from domain-name-based X.509 PKIs.  Such systems might (for example)
use RFC 1918 address space with iPAddress certificates, or pinned self-signed
certificates for TLS authentication.

A repeating theme was a desire by some participants to have some text as a
"hook" that indicates to sites that have already-fielded equipment
incompatible with the recommendations of this document that it is okay to
disregard its advice.  Other participants, however, expressed the sentiment
that a clear and unambiguous statement of best practices is preferred, with
many parties (presumably not the same ones that would benefit from the "hook")
having no difficulty in diverging from IETF guidelines.  Sentiments were
especially mixed as to the advisability of attempting to enumerate specific
exception cases where dropping old TLS versions would be harmful, as might
occur in such "hook" text.

There was also a proposal to keep TLS 1.0 and 1.1 enabled but treat it
identically to cleartext, though subsequent discussion concluded that
intentionally setting up a scenario where client and server disagree about
whether or not the traffic is secured seems ill-advised.

We heard about several classes of deployment for which an attempt to make this
change "overnight" would be a non-starter, with lead times measured in years
being necessary in order to achieve changes of this nature.  Fortunately, it
was clarified that publication of this document as a BCP would not require
such instant change; rather, this is the IETF describing what we believe to be
the best practices at the present time, with no immediate obligation to adhere
to such practices.  A transition period for moving from the present state of
any given deployment to the recommended state is called for, and this document
describes the motivation for the change so that each site can make an
assessment of their own risk and exposure, and thus, the pace at which to
transition.

In light of the expressed desire for long lead times in changes of this
nature, the question was raised as to when TLS 1.2 will be due for a similar
treatment, including whether it is advisable to choose and start advertising a
date for such a change now.  I note that TLS 1.3 features significant
improvements over TLS 1.2 on many axes, so I will encourage consideration
of this question in the TLS WG.

In conclusion, my assessment is that there is general IETF consensus to
publish this document in its current form, including the use of "MUST NOT"
language for the old TLS versions.  However, in the interest of clarity, we
should also provide some text to reiterate that this document reflects the
guidance from the IETF as to what are currently believed to be best practices
and why, but that whether or not (and how quickly) to adhere to the
IETF-provided best practices remains at the discretion of implementors and
operators.  Accordingly, I propose to add a new section just before the
Security Considerations section:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

7. Operational Considerations

This document is part of BCP 195, and as such reflects the understanding of
the IETF (at the time of its publication) as to the best practices for TLS
and DTLS usage.

Though TLS 1.1 has been obsolete since the publication of RFC 5246 in 2008,
and DTLS 1.0 has been obsolete since the publication of RFC 6347 in 2012,
there may remain some systems in operation that do not support (D)TLS 1.2 or
higher.  Adopting the practices recommended by this document for any systems
that need to communicate with the aforementioned class of systems will cause
failure to interoperate.  However, disregarding the recommendations of this
document in order to continue to interoperate with the aforementioned class of
systems incurs some amount of risk.  The nature of the risks incurred by
operating in contravention to the recommendations of this document are
discussed in Sections 2 and 3, and knowledge of those risks should be used
along with any potential mitigating factors and the risks inherent to
updating the systems in question when deciding how quickly to adopt the
recommendations specified in this document.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Thanks again for all the discussion here; it was quite productive.

-Ben

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 18:48:49 -0500

Benjamin, thanks for a very thorough summary of the discussion.

I was thinking about the use of 2119 keywords in the context of 
draft-ietf-v6ops-cpe-slaac-renum and realizing that there's a subtle but 
important difference between a BCP that says MUST NOT vs. a protocol 
specification that says MUST NOT:

In a BCP - MUST NOT presumably means "doing this violates what we 
consider best current practice".
In a protocol specification - MUST NOT means "a protocol implementation 
violates the standard if it does this"

A lot of my concern about draft-ietf-tls-oldversions-deprecate-09 is 
that it may be taken to mean that /implementations/ MUST NOT permit use 
of TLS versions < 1.2 even though there are valid reasons for doing 
so.   I think draft-ietf-tls-oldversions-deprecate would be Mostly 
Harmless if it were clear that it's only making operational 
recommendations that aren't binding on implementations, and that there 
may continue to be valid corner cases in which there's a need for 
implementations to be configurable to use older TLS versions. Perhaps 
language to this effect could be added in the proposed section 7 or 
elsewhere.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Dec 2020 15:59:48 -0800

On Tue, Dec 8, 2020 at 3:49 PM Keith Moore <[email-masked]>
wrote:

> In a BCP - MUST NOT presumably means "doing this violates what we consider
> best current practice".

Do you have a citation for this distinction? I believe that in both cases
this means "you are in violation of RFC XXXX if you do this".

A lot of my concern about draft-ietf-tls-oldversions-deprecate-09 is that
> it may be taken to mean that *implementations* MUST NOT permit use of TLS
> versions < 1.2 even though there are valid reasons for doing so.   I think
> draft-ietf-tls-oldversions-deprecate would be Mostly Harmless if it were
> clear that it's only making operational recommendations that aren't binding
> on implementations, and that there may continue to be valid corner cases in
> which there's a need for implementations to be configurable to use older
> TLS versions.   Perhaps language to this effect could be added in the
> proposed section 7 or elsewhere.
>
I would not be in favor of adding this text.

-Ekr

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 19:06:22 -0500

On 12/8/20 6:59 PM, Eric Rescorla wrote:

> On Tue, Dec 8, 2020 at 3:49 PM Keith Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     draft-ietf-v6ops-cpe-slaac-renum and realizing that there's a
>     subtle but important difference between a BCP that says MUST NOT
>     vs. a protocol specification that says MUST NOT:
>
>     In a protocol specification - MUST NOT means "a protocol
>     implementation violates the standard if it does this"
>
>
> Do you have a citation for this distinction? I believe that in both 
> cases this means "you are in violation of RFC XXXX if you do this".

Yes, but a BCP really does have a different meaning and scope than a 
standard protocol specification.

>     A lot of my concern about draft-ietf-tls-oldversions-deprecate-09
>     is that it may be taken to mean that /implementations/ MUST NOT
>     permit use of TLS versions < 1.2 even though there are valid
>     reasons for doing so.   I think
>     draft-ietf-tls-oldversions-deprecate would be Mostly Harmless if
>     it were clear that it's only making operational recommendations
>     that aren't binding on implementations, and that there may
>     continue to be valid corner cases in which there's a need for
>     implementations to be configurable to use older TLS versions.  
>     Perhaps language to this effect could be added in the proposed
>     section 7 or elsewhere.
>

I would counter that if the real goal of this document is to constrain 
implementations, it should be written as a standards-track document, and 
have been last called as a standards-track document, and to Last Call it 
as BCP was an error.

And I would be very much in objection to making this document a 
standards-track document.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 19:25:25 -0500

On 12/4/20 5:47 PM, Ted Lemon wrote:

> Why do people buy stuff that’s not upgradeable?

One reason I haven't seen listed yet - because in some scenarios upgrade 
capability is seen as a liability, or even a security vulnerability.   
And the people who see it that way are not always wrong.

Another reason, perhaps the most common one, is that there's no revenue 
stream to support it.

A third reason is that "upgrades" often break existing functionality - 
sometimes intentionally, sometimes accidentally.

A fourth is that upgrades haven't been established as a form of routine 
maintenance whether for operational stability or safety reasons; IOW 
there's been little effort to make upgrades fit into mindsets that are 
already well-established in industries.

There's no simple fix to these problems, and assuming that everything on 
the net should just be upgraded regularly (as if this is No Big Deal) is 
naive in the extreme.

Keith

p.s. I've been fixing an electromechanical clothes washer today, and 
realizing just how much I appreciate that there's no CPU in it.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Dec 2020 16:28:35 -0800

> standard protocol specification.
Hmm... I don't think that that's obvious. Do you have a textual argument
for this claim?

>> it may be taken to mean that *implementations* MUST NOT permit use of
>> TLS versions < 1.2 even though there are valid reasons for doing so.   I
>> think draft-ietf-tls-oldversions-deprecate would be Mostly Harmless if it
>> were clear that it's only making operational recommendations that aren't
>> binding on implementations, and that there may continue to be valid corner
>> cases in which there's a need for implementations to be configurable to use
>> older TLS versions.   Perhaps language to this effect could be added in the
> have been last called as a standards-track document, and to Last Call it as
> BCP was an error.
>
I think it's clear from the fact that this document updates a pile of other
documents and that we in fact have been looking at revisions to documents
in the pipeline makes clear that it is intended to constrain
implementations. We've done quite a number of other deprecation documents
as BCP and to the best of my knowledge they have generally been read this
way.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 19:38:06 -0500

On 12/8/20 7:28 PM, Eric Rescorla wrote:

>>     Do you have a citation for this distinction? I believe that in
>>     both cases this means "you are in violation of RFC XXXX if you do
>>     this".
>
>     Yes, but a BCP really does have a different meaning and scope than
>     a standard protocol specification.
>
> Hmm... I don't think that that's obvious. Do you have a textual 
> argument for this claim?

Maybe later.   But why have different statuses if they mean the same 
thing?   BCP was created specifically for a case that standards-track 
didn't work for.

>     I would counter that if the real goal of this document is to
>     constrain implementations, it should be written as a
>     standards-track document, and have been last called as a
>     standards-track document, and to Last Call it as BCP was an error.
>
> I think it's clear from the fact that this document updates a pile of 
> other documents and that we in fact have been looking at revisions to 
> documents in the pipeline makes clear that it is intended to constrain 
> implementations. We've done quite a number of other deprecation 
> documents as BCP and to the best of my knowledge they have generally 
> been read this way.

Maybe that practice needs to change, because it is starting to look like 
an end run around the standards process.

I was just to the point of concluding that this document was Mostly 
Harmless because it was only being LC'ed for BCP, and I think it's 
somewhat reasonable as a statement of best operational practice, but 
ONLY if it's confined to that scope.

Now that you're claiming it is intended to constrain implementations, I 
must strongly object to its publication in its current form.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Dec 2020 16:45:21 -0800

> thing?   BCP was created specifically for a case that standards-track
Candidly, 2026 is fairly vague on this point. With that said the rationale
in 2026 looks a lot more like "this doesn't need the three tier standards
system"

   Unlike standards-track documents, the mechanisms described in BCPs
   are not well suited to the phased roll-in nature of the three stage
   standards track and instead generally only make sense for full and
   immediate instantiation.

   The BCP process is similar to that for proposed standards.  The BCP
   is submitted to the IESG for review, (see section 6.1.1) and the
   existing review process applies, including a Last-Call on the IETF
   Announce mailing list.  However, once the IESG has approved the
   document, the process ends and the document is published.  The
   resulting document is viewed as having the technical approval of the
   IETF.

   Specifically, a document to be considered for the status of BCP must
   undergo the procedures outlined in sections 6.1, and 6.4 of this
   document. The BCP process may be appealed according to the procedures
   in section 6.5.

   Because BCPs are meant to express community consensus but are arrived
   at more quickly than standards, BCPs require particular care.
   Specifically, BCPs should not be viewed simply as stronger
   Informational RFCs, but rather should be viewed as documents suitable
   for a content different from Informational RFCs.

> Harmless because it was only being LC'ed for BCP, and I think it's somewhat
> reasonable as a statement of best operational practice, but ONLY if it's
> confined to that scope.
>
Well, speaking as someone with no authority, it appears to me that you are
in the minority in that opinion, but I'll leave the AD to handle it.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 19:50:25 -0500

On 12/8/20 7:45 PM, Eric Rescorla wrote:

>
>
> On Tue, Dec 8, 2020 at 4:38 PM Keith Moore <[email-masked] 
>>>         Do you have a citation for this distinction? I believe that
>>>         in both cases this means "you are in violation of RFC XXXX
>>>         if you do this".
>>
>>         Yes, but a BCP really does have a different meaning and scope
>>         than a standard protocol specification.
>>
>     Maybe later.   But why have different statuses if they mean the
>     same thing?   BCP was created specifically for a case that
>     standards-track didn't work for.
>
> Candidly, 2026 is fairly vague on this point. With that said the 
> rationale in 2026 looks a lot more like "this doesn't need the three 
> tier standards system"
>
Well, part of the difference might be that there are things (e.g. 
practices) that you can't generally test for interoperability, so you 
can't advance them along the standards track.
>    resulting document is viewed as having the technical approval of the

Yes, but asking for BCP when you really want to constrain 
implementations is like a bait-and-switch.  It's asking the community to 
evaluate the document in one light, when you intend it to be interpreted 
in a different light.

>     Now that you're claiming it is intended to constrain
>     implementations, I must strongly object to its publication in its
>     current form.
>
> Well, speaking as someone with no authority, it appears to me that you 
> are in the minority in that opinion, but I'll leave the AD to handle it.

This is a newly discovered issue, and there's been no input on this 
besides from you and me.

Keith

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 09 Dec 2020 12:05:45 +1100

On Wed, Dec 9, 2020, at 11:50, Keith Moore wrote:
> > Well, speaking as someone with no authority, it appears to me that 
> > you are in the minority in that opinion, but I'll leave the AD to 
> > handle it.

Hi Keith,

BCP 195 very much constrains implementations already.  I don't think your view holds here.

(I know that argument from precedent is a logical fallacy in many cases, but I think that it's the best argument here.)

Either way, the effect is the same: the document represents the consensus view of the IETF.

Cheers,
Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Dec 2020 17:55:00 -0800

On Tue, Dec 8, 2020 at 4:50 PM Keith Moore <[email-masked]>
wrote:

> practices) that you can't generally test for interoperability, so you can't
> advance them along the standards track.
>
>
> Yes, but asking for BCP when you really want to constrain implementations
> is like a bait-and-switch.  It's asking the community to evaluate the
> document in one light, when you intend it to be interpreted in a different
> light.
>
I'm curious, what do you think the point of having this update all the
other documents was if it wasn't to constrain implementations?

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 21:01:32 -0500

> other documents was if it wasn't to constrain implementations?

"updating" has always seemed very vague to me, but I tend to interpret 
it is "here's additional information that might be relevant to a reader 
of these old documents".

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 21:02:25 -0500

> Either way, the effect is the same: the document represents the consensus view of the IETF.

I disagree.  I don't think even rough consensus has been established.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2020 02:07:48 +0000

Hi Keith,

(replying to ekr, but really a question for you...)

> other documents was if it wasn't to constrain implementations?

When answering that, can you clarify what you mean by
"constrain" and where there's a downside to your idea
of that? It's not clear to me at any rate.

Thanks,
S.

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 21:21:17 -0500

> of that? It's not clear to me at any rate. 

Because the requested status was Best Current Practice, I didn't 
interpret this document as saying that implementations of TLS must 
prevent operators from enabling TLS versions prior to 1.2. ("Best" 
implies that other practices can be chosen.)

The downside is that operators may effectively be forced to break 
interoperability with existing clients and/or servers, that provide 
essential functionality, if some of their software is upgraded to 
reflect the recommendations in 
draft-ietf-tls-oldversions-deprecate-09.   They may be forced to do this 
even when the operators have valid operational reasons for continuing to 
use TLS < 1.2, have explicitly evaluated the risks with doing so, used 
their exception processes to justify doing so, etc.   (Because it's 
generally not feasible to postpone upgrades indefinitely or sometimes 
even for a short time; there are often interdependencies that preclude 
doing that.)

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2020 02:36:27 +0000

Hiya,

> implies that other practices can be chosen.)

ISTM the "MUST NOT" bits of the draft are pretty clear, and I
don't see how they ever could have been unclear. (One could
disagree as to the wisdom and timeliness of course, but
that's a different issue.) For example, it says "TLSv1.0 MUST
NOT be used.  Negotiation of TLSv1.0 from any version of TLS
MUST NOT be permitted." My interpretation of Ben's mail was
that the responsible AD figured there was IETF consensus for
those MUST NOT statements. The IESG will or won't (dis)agree
with that when they get to it.

That said, the text does not "prevent" implementers from
doing whatever they want, it just expresses (what may turn
out to be) IETF consensus on the topic.

> draft-ietf-tls-oldversions-deprecate-09.Â Â  They may be forced to do 
> this even when the operators have valid operational reasons for 
> continuing to use TLS < 1.2, have explicitly evaluated the risks with 
> doing so, used their exception processes to justify doing so, etc.Â Â  
> (Because it's generally not feasible to postpone upgrades indefinitely 
> or sometimes even for a short time; there are often interdependencies 
> that preclude doing that.)

So regardless of one's opinion on that topic, I think it's
fair to say the paragraph above doesn't raise a new point.
Anyone can of course continue to use TLSv1.0 (or SSLv3 if
perverse reality requires that;-) and the net result is only
that they won't conform to our latest BCPs. I think that's
ok myself.

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Dec 2020 18:46:03 -0800

Hi Keith,

> implies that other practices can be chosen.)

I don't think that there is anything surprising about the mechanics of the
"Updates:" relationship here (even if we have recently established that
there is not widespread agreement about when the "Updates:" tag should be
used).  To take some concrete numbers as an example, suppose that this
draft becomes RFC 9001 (an arbitrarily selected number).  It has an
Updates: relationship to RFC 3261.  RFC 3261 existed 18 years ago, exists
now, and will continue to exist when RFC 9001 is published.  You can
implement it.  Your implementation remains RFC 3261 compliant even as RFC
3261 is updated by RFC 9001.  Now when RFC 9001 comes around, there is some
kind of abstract logical entity that is
RFC-3261-with-RFC-9001-updates-applied.  An implementation of that combined
entity (that implements TLS at all, as RFC 3261 doesn't seem to require a
TLS implementation) will use TLS 1.2 as the minimum TLS version.  An
implementation of RFC 3261 might use TLS 1.0 as the minimum TLS version
and would be perfectly justified in continuing to do so even after RFC 9001
exists.  Compliance with either RFC 3261 or RFC-3261-as-updated-by-RFC-9001
remains optional.

This is all bog-standard Updates: relationships and all of these Updates:
headers were in the draft that went to IETF Last Call.  We even had some
people explicitly call out their support for doing it this way with the
pile of Updates:.

> draft-ietf-tls-oldversions-deprecate-09.   They may be forced to do this 

Yes.  That's why I proposed text to say exactly that.  Operators can decide
which risk they want to bear, based on the best information we are able to
provide at the current time.  They can also supply input to implementations
as to their operational reality and requirements.

> their exception processes to justify doing so, etc.   (Because it's 

I'm sorry; I don't follow this step.  Who is forcing anything?  I can
assure you that the IETF is not.

> even for a short time; there are often interdependencies that preclude 

If you are constrained to not take certain updates for whatever reason,
there are some other updates you may not safely be able to take.  Not all
patches are commutative.  How is this new?

Thanks,

Ben

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 22:27:19 -0500

> with that when they get to it.

To me "MUST NOT" only made sense in the context of "Best Current 
Practice" as in "if you violate this MUST NOT, you aren't conforming to 
this recommendation".   Because to absolutely forbid implementations to 
use TLS < 1.2 in all circumstances is unacceptably disruptive.   The 
only thing that made the document at all acceptable was that the 
intended status was BCP.

I also think that consensus on one status (if it exists) does not equate 
to consensus on another status.   The community was asked to evaluate 
the document as a Best Current Practice, which clearly means something 
different than evaluating it as a protocol specification.

> out to be) IETF consensus on the topic.

Right.   There are still no Protocol Police as far as I know. But the 
practical effect of publishing this document may be that implementations 
remove support for TLS 1.0 and 1.1, even though (as Kathleen pointed 
out) an organization might explicitly decide to accept the business risk 
of continuing to use one or both of those.

> that they won't conform to our latest BCPs. I think that's

Practically speaking, "anyone" probably cannot do that.  You or I and 
some others here are technically capable of that if we had the time to 
spare, but probably few if any of us does.

 From the recent conversation it seems clear that a primary goal of this 
document is not merely to make recommendations about operational 
practice, but to actually reduce the options available to operators.  To 
eradicate TLS < 1.2 like we'd like to eradicate COVID.

------

I want to take a step back.   I don't think it's appropriate to use BCP 
as a way to get implementations to remove support for TLS < 1.2.   I 
also think if people ask the community to approve a document, then they 
should be really clear and consistent about what they're asking for.  In 
my mind the Right Thing to do from a process standpoint is to make the 
document text and intended status clear and consistent with one another 
and Last Call it again.

But I also seriously doubt that debates over document status will result 
in a transition to TLS >= 1.2 with less disruption to essential 
operations (which is in fact my goal), or (sadly) even a clearer 
document.  All of my IETF experience (that I can remember) says that 
late debates only serve to consume time and energy, frustrate people, 
delay the result, and muddy the waters even more.   So I don't want to 
take things in that direction.

I certainly want to see stronger encryption and wider use of encryption, 
and am sensitive to the notion that implementations that support older 
versions of TLS can often be subjected to downgrading attacks.   But I 
also want existing uses of TLS < 1.2 that can't easily be upgraded to 
NOT have to run old operating systems and/or old clients/servers and/or 
old hardware (with the associated additional security vulnerabilities) 
just to be able to continue to work until, say, the legacy hardware can 
be replaced, the existing assembly lines can be dismantled, etc.

And I guess I just think that this document needs to acknowledge that 
problem and allow some wiggle room for operators who have to deal with it.

Keith

---

From: Mike Bishop <[email-masked]>
Date: Wed, 9 Dec 2020 03:59:39 +0000

BCP 195 seems very clear, though: it prefaces the list of "MUST NOT"s with text calling them "recommendations."

Both sides seem to have a logically consistent viewpoint here, but it hinges on what the meaning and scope of a BCP actually is. Interpreting the name, "Best Current Practice" should mean that it's a statement on what the IETF believes is the best choice at the moment. It does feel strange that a BCP can make normative updates to Standards-track documents, precedent or not. I totally see why Keith feels like this is an end-run around the Standards process; if that's valid, then BCP isn't quite what it sounds like it should be. I don't see anything in BCP 9 that prohibits doing so, but making changes to protocol requirements doesn't feel like it's in the spirit of what BCP 9 Section 5 describes.

Publishing this (on either track) does not mean all implementations will conform or need to conform. Just as business pressures will cause some deployments to still use old versions, they will exert business pressure on the implementations they use to keep support for those old versions. Some will, and some won't. That's a consideration outside the IETF's purview.

This document says that the IETF's best guidance is not to use old crypto at all, even with protocols that mandated old TLS versions. I don't think that's a false statement, so publishing is probably fine; I would be more certain about that if it were Standards track instead of BCP.

Personally, I think this discussion highlights more about the lack of clarity around what BCPs are than about the document itself.

Sent from Nine<http://www.9folders.com/>
________________________________
From: Martin Thomson <[email-masked]>
Sent: Tuesday, December 8, 2020 8:07 PM
To: [email-masked]
Subject: Re: [Last-Call] Results of Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi Keith,

Cheers,
Martin

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Dec 2020 00:23:06 -0500

(Changing the subject line and copying the IETF list for reasons
that will become obvious.  I hope that any follow-up will occur
on the IETF list only.)

--On Tuesday, December 8, 2020 19:38 -0500 Keith Moore
<[email-masked]> wrote:

>> I think it's clear from the fact that this document updates a
>> pile of  other documents and that we in fact have been
>> looking at revisions to  documents in the pipeline makes
>> clear that it is intended to constrain  implementations.
>> We've done quite a number of other deprecation  documents as
>> BCP and to the best of my knowledge they have generally  been
>> read this way.
> 
> Maybe that practice needs to change, because it is starting to
> look like an end run around the standards process.
> 
> I was just to the point of concluding that this document was
> Mostly Harmless because it was only being LC'ed for BCP, and I
> think it's somewhat reasonable as a statement of best
> operational practice, but ONLY if it's confined to that scope.
> 
> implementations, I must strongly object to its publication in
> its current form.

Keith,

First, thanks to Ben for what is, IMO, an excellent and fair
summary.  Period.  Not "but..." or "let's continue litigating
this already too-long thread".

I believe that there has been a increasing tendency in recent
years to use the BCP category for documents that, if 2026 were
taken seriously, would be required to be ordinary Technical
Specification or Applicability Statement documents.  My reading
of 2026 (including the paragraphs quoted by ekr) as well as the
distinction I think you are making is that a BCP should never be
used to alter the technical content of a standards track
document.  If we have a document, RFC NNNN that says "you MUST
do this in so-and-so way", then a BCP that says "regardless of
what RFC NNNN says, the best practice is to do it is this other
way".  That would (and, IMO, has) put us in the rather odd
position of defining something as a Standard (even if only a
"Proposed" one) and then turning around and saying "don't take
our standards seriously".  IMO, not good.

Saying in a BCP "the MUST in that other spec may have been a
little too strong" or "here a some circumstances in which a
SHOULD does not apply" are in more of a gray area.  

So, yes, I think a specification like this should have been
written somewhat differently and then published as a an updating
Technical Specification or as an Applicability Statement.   The
latter would, IMO, have been especially appropriate because
classifying those problem methods as "Limited Use" and then
explaining why people should be phasing them out  and why they
might not want to hurry to do that is precisely in line with
what A/S documents are supposed to be all about.  That was part
of what I was getting at when I asked for the clarification that
Ben mentioned.   However, because we have been using BCPs in
this way for quite a while, I don't think it is fair or
reasonable to jump on a WG that has gotten a document into Last
Call and say "despite all of the precedent for this, it is your
bad luck week and you need to go back to the drawing board".

So, IMO, if this situation is going to be straightened out, we
should let this document go with Ben's suggested changes but
should go back to the IETF list and push for some changes,
ideally binding on the IESG, which prevents our getting into
this kind of situation again.  In other words, while I think
this document  is a mistake as written, I think the authors and
WG are victims and we should not punish them for it.  Instead,
we should learn from this example and work to avoid its
happening again.  Or we should find out that the community does
not care and then proceed to revise 2026 accordingly.

    john

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Dec 2020 22:21:18 -0800

> our standards seriously".  IMO, not good.

We could look at process, or we could look at technology. Take for 
example one of the updated RFC, 3856, "A Presence Event Package for the 
Session Initiation Protocol (SIP)". The text says that it basically uses 
TLS to secure the connection. Changing the version of TLS has no 
functional impact on the specification, which relies only on 
version-independent properties of TLS such as confidentiality and 
authentication. The text only mentions a "version" of TLS through its 
references to RFC 2246, TLS 1.0, which was the version of TLS current at 
the time. Yes, the authors of that RFC did not write "TLS 1.0 or a later 
version". Had they done that, there would be no process issue. And I 
think that if we want a narrow process decision, we should start there: 
applications should anticipate that security requirements will change 
over time, and say something like "current version of TLS [RFC XXXX] or 
later."

-- Christian Huitema

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 9 Dec 2020 07:27:11 -0500

+1 (as a & discussant on RFC 1818 and as the editor of 2026 )

Scott

> On Dec 9, 2020, at 12:23 AM, John C Klensin <[email-masked]> wrote:
>

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Dec 2020 05:02:29 -0800 (PST)

+1 as well. The problem of BCPs modifying standards needs to be addressed,
but this is not the right context for that to happen. The operational
considerations text that has been proposed is sufficiently curative that
it is OK for this document to move forward with that addition.

				Ned

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Dec 2020 14:27:00 +0000

>  I think draft-ietf-tls-oldversions-deprecate would be Mostly Harmless

Good grief!  I don’t understand why anyone would want a document that explains why not to use obsolete weak versions of a protocol to be mostly harmless.  I can’t even.

---

From: Martin Duke <[email-masked]>
Date: Wed, 9 Dec 2020 13:17:36 -0800

If making this a Standard instead of BCP makes everyone happy with the
process, I have no problem with that.

This distinction will have no impact in the real world at all.

On Wed, Dec 9, 2020 at 6:27 AM Salz, Rich <rsalz=[email-masked]>
wrote:

> Good grief!  I don’t understand why anyone would want a document that
> explains why not to use obsolete weak versions of a protocol to be mostly
> harmless.  I can’t even.
> --
> last-call mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Dec 2020 14:53:13 +0000

Hi Tom,

On 10/11/2020 11:33, Stephen Farrell wrote:
> 
> 
> On 10/11/2020 11:30, tom petch wrote:
>> Perhaps a second look at the algorithm 
>> to work out why these got missed to get a fix on how many more there may be. 
>>
> 
> Sure, that's reasonable. (Mightn't be today.)

Just did that check by comparing [1] to the RFCs
referenced in the draft and best I can see only
5953 and 6353 were missing in the end.

I'd argue it's ok to add those without re-doing
the IETF LC as they were mentioned in early on,
in the LC, but of course that's the AD's call.

I'm doing the edits for draft-10 now so it'll
pop out shortly.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/rfc4347/referencedby/

---

From: tom petch <[email-masked]>
Date: Mon, 14 Dec 2020 16:36:22 +0000

> I'm doing the edits for draft-10 now so it'll

Stephen

Thank you for checking. With those two being SNMP
and having both DTLS and TLS I was thinking of
conspiracy theories but no:-)
I should see the announcement of the updated I-D
and will check it when I do.
Like you, I do not see the need for a further LC
just for the addition of those two RFC,

Tom Petch

---

From: tom petch <[email-masked]>
Date: Tue, 15 Dec 2020 12:51:01 +0000

>> I'm doing the edits for draft-10 now so it'll

Stephen, indeed, it had popped while I was replying to your e-mail.

I see RFC5953, RFC6353 have been added.  RFC5953 is obsoleted so should 
it be listed in 1.1 in the list of RFC already obsoleted, the one that 
start with RFC5101?

Tom Petch

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Dec 2020 15:14:29 +0000

Hiya,

> it be listed in 1.1 in the list of RFC already obsoleted, the one that 

Argh/oops:-)

I just posted -11 fixing that.

Thanks,
S.

---

From: tom petch <[email-masked]>
Date: Wed, 16 Dec 2020 09:58:00 +0000

Stephen,

I have downloaded -11 (using FTP, of course:-) and it looks good to me,

Tom Petch