Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Artyom Gavrichenkov]

Good day!

On Sun, Aug 19, 2018 at 3:01 AM Stephen Farrell
 wrote:
> 1. The bit you quote above is incomplete

Yep, but the rest of the paragraph just outlines *recommendations*
(or, even better, 'encouragements') while the draft states that "PCI
Council [is] deprecating TLSv1.0 and TLSv1.1 by June 30, 2018".

In the PCI world, *deprecation* is commonly thought to be a
*requirement*, not a recommendation. It is *not recommended* to use
TLSv1.1 (and TLSv1.2) already just by virtue of fact that a more
up-to-date spec version exists.

My point here is that this wording is not, strictly speaking, correct
-- so far, as a matter of fact.

(In fact, PCI DSS even still allows usage of SSLv3 under certain
circumstances -- e.g. POS/POI, -- but said circumstances are strict
enough for us to conveniently omit mentioning those).

> 2. Use of TLSv1.1 seems to be almost non-existent. See the figures
> in the -01 draft for some detail [..]

Maybe, but this is irrelevant to the concern I've raised. If you want
PCI SSC to deprecate TLSv1.1 just because enterprise networks are not
using it, the right way to do it is to share the data with the SSC
along with the research methodology and let them decide.

By the way, at least one issue with the research data referred to in
draft-diediedie-01 which I'm aware of is that the researchers were
hunting for open 443/tcp port only, while the enterprises have a
practice to move deprecated services those enterprises somehow cannot
get rid of to different ports, like, 4443, 4433, 8443 and so on.

To make it absolutely clear, I'm not criticizing the methodology now,
however, I just want to raise a concern that if PCI SSC somehow
decided to deprecate v1.0 (far ahead of IETF) but still keep v1.1
then, *maybe*, they had at some point in time a strong reason to do
so. It's entirely fine to ignore their preferences and let PCI SSC
'catch up' without quoting themselves as a reference, or, vice versa,
it's okay to quote the SSC while sticking to their actual suggestions.

Just in case, I'm not in any way against the draft-diediedie. I
support it, which is why I've voted for the WG adoption before posting
this to the mailing list. I'm just a nerd who wants the document to be
consistent for that matter, and that's it.

--
Töma

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

Thanks for reading the draft!

On 19/08/18 00:45, Artyom Gavrichenkov wrote:
> On Mon, Jul 9, 2018 at 7:42 PM Kathleen Moriarty
>  wrote:
>> Stephen and I posted the draft below to see if the TLS working group
>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
>> been a recent drop off in usage for web applications due to the PCI
>> Council recommendation to move off TLSv1.0, with a recommendation to
>> go to TLSv1.2 by June 30th.
> 
> Err, sorry, but – to make it one hundred per cent correct – it seems
> like PCI SSC has just deprecated TLS v1.0 _only_.
> 
> "Migrating from SSL and Early TLS", version 1.1:
> "The best response is to disable SSL entirely and migrate to a more
> modern encryption protocol, which at the time of publication is a
> minimum of TLS v1.1"
> https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf
> 
> draft-moriarty-diediedie also mentions PCI SSC requirements. Do I get
> anything wrong here?

Well, two comments:

1. The bit you quote above is incomplete, the full paragraph says
"The best response is to disable SSL entirely and migrate to a more
modern encryption protocol, which at the time of publication is a
minimum of TLS v1.1, although entities are strongly encouraged to
consider TLS v1.2.  Note that not all implementations of TLS v1.1
are considered secure – refer to NIST SP 800-52 rev 1 for guidance
on secure TLS configurations." So there's already a strong hint
in PCI-land to GOTO TLSv1.2+.

2. Use of TLSv1.1 seems to be almost non-existent. See the figures
in the -01 draft for some detail, (and more data is always welcome).
It seems like there's more already-deprecated SSL than there is
TLSv1.1 which I think means that this is really a non-issue.

I guess there could be a formal but theoretical problem resulting
from this, but OTOH, if (or when) the IETF finished an RFC based
on this draft deprecating these legacy versions then PCI folks can
catch up, and without that affecting pretty much anyone, so I'd say,
in this case, it's likely ok to just ignore this slight discrepancy.
But if you've some text change to suggest that'd handle it better,
that'd be great to see.

Cheers,
S.


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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Artyom Gavrichenkov]

On Mon, Jul 9, 2018 at 7:42 PM Kathleen Moriarty
 wrote:
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off TLSv1.0, with a recommendation to
> go to TLSv1.2 by June 30th.

Err, sorry, but – to make it one hundred per cent correct – it seems
like PCI SSC has just deprecated TLS v1.0 _only_.

"Migrating from SSL and Early TLS", version 1.1:
"The best response is to disable SSL entirely and migrate to a more
modern encryption protocol, which at the time of publication is a
minimum of TLS v1.1"
https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf

draft-moriarty-diediedie also mentions PCI SSC requirements. Do I get
anything wrong here?

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Jeremy Harris]

On 07/09/2018 05:40 PM, Kathleen Moriarty wrote:
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off TLSv1.0, with a recommendation to
> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
> as a baseline.  Applications other than those using HTTP may not have
> had the same reduction in usage.  If you are responsible for services
> where you have a reasonable vantage point to gather and share
> statistics to assess usage further, that could be helpful for the
> discussion.
I have access to stats from a small UK-based ESP.  Of the inbound:

SMTP connections in plaintext: 15%

Of TLS:
SMTP using TLS version prior to 1.2 :  20%
SMTP using TLSv1.1  :  0.03%


I note specifically that Facebook notification mails use TLSv1.0
-- 
Cheers,
  Jeremy

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Hubert Kario]

On Saturday, 14 July 2018 18:59:01 CEST Yaron Sheffer wrote:
> >>> I'd encourage you to try get people to be open about
> >>> things here - there's no particular shame in having 10% TLSv1.0
> >>> sessions after all:-)
> >> 
> >> It isn't a question of shame but it is just a bit too much information
> >> to provide a potential adversary.  That is, to say that Stock Exchange
> >> XYZ
> >> has n% of TLS1.0 clients provides a potential attacker too much
> >> information.
> > 
> > Not sure I agree there tbh. If they're externally visible
> > services, then it's public already. If they're not, and the
> > attacker is inside the n/w, then the bad actor can find it
> > out then. But I do understand organisations being shy about
> > such things.
> 
> Having gone through this exercise recently, I agree with Nalini on why
> people would not want to report openly.
> 
> For a typical enterprise, 10% TLS 1.0 in the internal network could well
> mean that 10% of your servers are Java boxes that have not been updated
> in the last two years (and so are riddled with vulnerabilities that are
> much more severe than the old TLS version). Absolutely a good reason to
> be ashamed :-) and certainly not information that you'd want to share
> openly.

or fully updated and supported RHEL-5 servers...

that data point alone is far too little to say if the use of TLS 1.0 is 
shameful or not

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Yaron Sheffer]

I'd encourage you to try get people to be open about
things here - there's no particular shame in having 10% TLSv1.0
sessions after all:-)


It isn't a question of shame but it is just a bit too much information
to provide a potential adversary.  That is, to say that Stock Exchange XYZ
has n% of TLS1.0 clients provides a potential attacker too much
information.


Not sure I agree there tbh. If they're externally visible
services, then it's public already. If they're not, and the
attacker is inside the n/w, then the bad actor can find it
out then. But I do understand organisations being shy about
such things.



Having gone through this exercise recently, I agree with Nalini on why 
people would not want to report openly.


For a typical enterprise, 10% TLS 1.0 in the internal network could well 
mean that 10% of your servers are Java boxes that have not been updated 
in the last two years (and so are riddled with vulnerabilities that are 
much more severe than the old TLS version). Absolutely a good reason to 
be ashamed :-) and certainly not information that you'd want to share 
openly.


Thanks,
Yaron

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Christopher Wood]

(Chair hat off.)

On Wed, Jul 11, 2018 at 10:37 AM, David Benjamin  wrote:
> On Mon, Jul 9, 2018 at 12:58 PM Eric Rescorla  wrote:
>>
>> On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla  wrote:
>>>
>>> Thanks for writing this.
>>>
>>> I would be in favor of deprecating old versions of TLS prior to 1.2.
>>> Firefox Telemetry shows that about 1% of our connections are TLS 1.1
>>
>>
>> This should be 1.0.
>>
>>
>>> (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
>>>
>>> This is probably a higher number than we'd be comfortable turning off
>>> immediately, but it is probably worth starting the process.
>
>
> Metrics from Chrome report 0.43% of our connections are TLS 1.0 and 0.03% of
> them are TLS 1.1, which is a similar situation. I too am in favor of
> deprecating them and getting things started.

Our system-wide metrics indicate 0.36% and 99.6% of connections are
TLS 1.0 and 1.2, respectively. This does not include all code paths,
though it covers the overwhelming majority of use cases, including
mobile mail. Thus, similar to others, I'm in favor of deprecating TLS
1.0 and 1.1.

Best,
Chris

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

On 13/07/18 13:24, nalini elkins wrote:
> Stephen,
> 
> Sorry for the late reply.   I was travelling to Montreal from India and
> was jet lagged.

No problem. And that'll be me tomorrow:-)

I generally agree with Ekr's mail just now but a little bit
more below...

> 
>>
>>> I am thinking the following:
>>>
>>> Location: U.S. / Canada (possibly U.K.)
>>>
>>> -  3 banks (hopefully from the top 5)
>>> -  3 large insurance companies  (includes back end processing)
>>> -  3 U.S. federal government agencies
>>> -  3 companies in the Wall Street / Stock brokerage sector (includes back
>>> end processing)
>>> -  3 large credit card / processors (ex. Visa, Discover, MasterCard,
> etc.)
>>> -  3 in the retail sector (Home Depot, Target, Lowes, et al)
> 
>> Those are pretty small numbers unless they're interacting with
>> a lot of TLS services. It'd be hard to know if they'd be
>> representative of something or not if they're anonymised in the
>> results.
> 
> I would expect that these people would have quite a few applications
> using TLS.   Telnet, FTP, MQSeries, SMTP, and many written by the
> organization itself.
> 
> What numbers do you feel WOULD be representative?

Well, for externally visible services, that information is
public already and visible via e.g. censys.io and similar
so you could just omit those from any numbers you report I
guess.

I've not thought so much about things that are only visible
internally, though I did (have a student:-) do some scanning
of our university n/w early this year, but I've yet to look
at that data so a) I still need to verify it, and b) I'm not
sure how I'd report on it in detail. That said, what he
reported for port 443, was ~800 regularly seen servers in
the bits of n/w he scanned with:

 SSLv3 (18%),
 TLSv1.0 (35%),
 TLSv1.1 (0%),
 TLSv1.2 (45%),
 TLSv1.3 (0%)

Which is a tad sad;-( I think many of the SSLv3 and TLSv1.0
servers were on things like printers, conferencing boxes,
access points and servers that are have basically been left
running when nobody cares for 'em any more. But that's the
bit I'd like to go re-check before standing over those
numbers. And I'd also like to know more about how those
change over time too, and look at other ports and not just
443. (Doing that is somewhere down towards the end of my
to-do list but maybe I'll set another student on it later
in the year.)

If you could quote figures (and rate of change) like those
for identified networks that'd I think be useful. If you
anonymise and/or aggregate then it's a bit harder to know
how to interpret the data. (E.g. the fact we're a university
likely means we've more forgotten web servers I guess;-).
And if they're guesses and not measurements, or if it's not
clear what was measured, then it's really not so useful.

I guess the thing to keep in mind is that it's better if
the findings can be replicated or otherwise validated. (If
it helps, my student's scanning code is at [1] but I reckon
there's a good bit of work to be done to make that usable
for anyone else.)

>> I'd encourage you to try get people to be open about
>> things here - there's no particular shame in having 10% TLSv1.0
>> sessions after all:-)
> 
> It isn't a question of shame but it is just a bit too much information
> to provide a potential adversary.  That is, to say that Stock Exchange XYZ
> has n% of TLS1.0 clients provides a potential attacker too much
> information.  

Not sure I agree there tbh. If they're externally visible
services, then it's public already. If they're not, and the
attacker is inside the n/w, then the bad actor can find it
out then. But I do understand organisations being shy about
such things.

Cheers,
S.

[1] https://github.com/mikeyPower/final-year-project

> As I say, most organizations that I know are trying very hard
> to migrate from older versions.  It is not as simple as it might seem.
> 
> If the organizations need to be identified by name, then I think this will
> be a show stopper for any kind of data that I might be able to provide.
> Having said that, I completely understand (and share) your distrust of
> anonymous data.   I am at a loss as to how to proceed.
> 
> I am open to any constructive suggestions.
> 
> Thanks,
> Nalini
> 
> 
> On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell 
> wrote:
> 
>>
>> Hiya,
>>
>> On 11/07/18 06:45, nalini elkins wrote:
>>>  Stephen,
>>>
 I'd love to add more detail like that and/or more sections for other
>>> protocols if folks have data to offer with references.
>>>
>>> I believe that I can reach out to various people I know.   Please comment
>>> if my methodology is acceptable and if you think this will be helpful.
>>
>> It's not whether the methodology is acceptable to me or not
>> but whether or not the references to the numbers are credible
>> for readers:-)
>>
>> A few comment below,
>>
>>>
>>> I am thinking the following:
>>>
>>> Location: U.S. / Canada (possibly U.K.)
>>>
>>> -  3 banks (hopefully from the top 5)
>>> -  3 large 

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Eric Rescorla]

On Fri, Jul 13, 2018 at 5:24 AM, nalini elkins 
wrote:

> Stephen,
>
> Sorry for the late reply.   I was travelling to Montreal from India and
> was jet lagged.
>
> >
> >> I am thinking the following:
> >>
> >> Location: U.S. / Canada (possibly U.K.)
> >>
> >> -  3 banks (hopefully from the top 5)
> >> -  3 large insurance companies  (includes back end processing)
> >> -  3 U.S. federal government agencies
> >> -  3 companies in the Wall Street / Stock brokerage sector (includes
> back
> >> end processing)
> >> -  3 large credit card / processors (ex. Visa, Discover, MasterCard,
> etc.)
> >> -  3 in the retail sector (Home Depot, Target, Lowes, et al)
>
> >Those are pretty small numbers unless they're interacting with
> >a lot of TLS services. It'd be hard to know if they'd be
> >representative of something or not if they're anonymised in the
> >results.
>
> I would expect that these people would have quite a few applications
> using TLS.   Telnet, FTP, MQSeries, SMTP, and many written by the
> organization itself.
>
> What numbers do you feel WOULD be representative?
>
> > I'd encourage you to try get people to be open about
> > things here - there's no particular shame in having 10% TLSv1.0
> > sessions after all:-)
>
> It isn't a question of shame but it is just a bit too much information
> to provide a potential adversary.  That is, to say that Stock Exchange XYZ
> has n% of TLS1.0 clients provides a potential attacker too much
> information.
>

Well, this seems like it is primarily true due to deficiencies in TLS 1.0
or the software running it, in which case so much the more reason
to recommend updating.


 As I say, most organizations that I know are trying very hard
> to migrate from older versions.  It is not as simple as it might seem.
>
> If the organizations need to be identified by name, then I think this will
> be a show stopper for any kind of data that I might be able to provide.
> Having said that, I completely understand (and share) your distrust of
> anonymous data.   I am at a loss as to how to proceed.
>

As I said earlier, I don't think the deployment fraction is that relevant
here.

The question of whether the IETF should deprecate TLS 1.2 is primarily
one we should make based on the technical merits of the older protocol
versions compared to TLS 1.2. Given that we know that 1.2 is more
secure and that 1.0 has serious deficiencies, it seems like the two next
questions are:

1. Are there respects in which TLS 1.2 is not an adequate replacement
for TLS 1.0? I think the answer here is pretty much no. [0]
2. Is the deployment of TLS 1.2 so low that it's just silly to tell people
to
cut over. That's clearly not true in the Web environment, though perhaps
it's true in some other environment. However, that would be a number
more like 30% TLS 1.0 rather than 5-10%. Is the number that high?

Absent those things, then it's a sensible recommendation for the
IETF to make.

-Ekr

[0] This is less obvious for TLS 1.3 in that we removed features with
low usage.




> I am open to any constructive suggestions.
>
> Thanks,
> Nalini
>
>
> On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>>
>> Hiya,
>>
>> On 11/07/18 06:45, nalini elkins wrote:
>> >  Stephen,
>> >
>> >> I'd love to add more detail like that and/or more sections for other
>> > protocols if folks have data to offer with references.
>> >
>> > I believe that I can reach out to various people I know.   Please
>> comment
>> > if my methodology is acceptable and if you think this will be helpful.
>>
>> It's not whether the methodology is acceptable to me or not
>> but whether or not the references to the numbers are credible
>> for readers:-)
>>
>> A few comment below,
>>
>> >
>> > I am thinking the following:
>> >
>> > Location: U.S. / Canada (possibly U.K.)
>> >
>> > -  3 banks (hopefully from the top 5)
>> > -  3 large insurance companies  (includes back end processing)
>> > -  3 U.S. federal government agencies
>> > -  3 companies in the Wall Street / Stock brokerage sector (includes
>> back
>> > end processing)
>> > -  3 large credit card / processors (ex. Visa, Discover, MasterCard,
>> etc.)
>> > -  3 in the retail sector (Home Depot, Target, Lowes, et al)
>>
>> Those are pretty small numbers unless they're interacting with
>> a lot of TLS services. It'd be hard to know if they'd be
>> representative of something or not if they're anonymised in the
>> results. I'd encourage you to try get people to be open about
>> things here - there's no particular shame in having 10% TLSv1.0
>> sessions after all:-)
>>
>> >
>> > Note: I put in "back end processing" because these are the folks that
>> most
>> > often have many connections to other business partners and so in some
>> ways
>> > have the most complex systems to deal with.
>> >
>> > Note #2:  This is aspirational!  I hope I can get all these people to
>> > cooperate.  I will try at least to get some in each category.
>> >
>> >
>> > I will ask them 

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[nalini elkins]

Stephen,

Sorry for the late reply.   I was travelling to Montreal from India and
was jet lagged.

>
>> I am thinking the following:
>>
>> Location: U.S. / Canada (possibly U.K.)
>>
>> -  3 banks (hopefully from the top 5)
>> -  3 large insurance companies  (includes back end processing)
>> -  3 U.S. federal government agencies
>> -  3 companies in the Wall Street / Stock brokerage sector (includes back
>> end processing)
>> -  3 large credit card / processors (ex. Visa, Discover, MasterCard,
etc.)
>> -  3 in the retail sector (Home Depot, Target, Lowes, et al)

>Those are pretty small numbers unless they're interacting with
>a lot of TLS services. It'd be hard to know if they'd be
>representative of something or not if they're anonymised in the
>results.

I would expect that these people would have quite a few applications
using TLS.   Telnet, FTP, MQSeries, SMTP, and many written by the
organization itself.

What numbers do you feel WOULD be representative?

> I'd encourage you to try get people to be open about
> things here - there's no particular shame in having 10% TLSv1.0
> sessions after all:-)

It isn't a question of shame but it is just a bit too much information
to provide a potential adversary.  That is, to say that Stock Exchange XYZ
has n% of TLS1.0 clients provides a potential attacker too much
information.   As I say, most organizations that I know are trying very hard
to migrate from older versions.  It is not as simple as it might seem.

If the organizations need to be identified by name, then I think this will
be a show stopper for any kind of data that I might be able to provide.
Having said that, I completely understand (and share) your distrust of
anonymous data.   I am at a loss as to how to proceed.

I am open to any constructive suggestions.

Thanks,
Nalini


On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 11/07/18 06:45, nalini elkins wrote:
> >  Stephen,
> >
> >> I'd love to add more detail like that and/or more sections for other
> > protocols if folks have data to offer with references.
> >
> > I believe that I can reach out to various people I know.   Please comment
> > if my methodology is acceptable and if you think this will be helpful.
>
> It's not whether the methodology is acceptable to me or not
> but whether or not the references to the numbers are credible
> for readers:-)
>
> A few comment below,
>
> >
> > I am thinking the following:
> >
> > Location: U.S. / Canada (possibly U.K.)
> >
> > -  3 banks (hopefully from the top 5)
> > -  3 large insurance companies  (includes back end processing)
> > -  3 U.S. federal government agencies
> > -  3 companies in the Wall Street / Stock brokerage sector (includes back
> > end processing)
> > -  3 large credit card / processors (ex. Visa, Discover, MasterCard,
> etc.)
> > -  3 in the retail sector (Home Depot, Target, Lowes, et al)
>
> Those are pretty small numbers unless they're interacting with
> a lot of TLS services. It'd be hard to know if they'd be
> representative of something or not if they're anonymised in the
> results. I'd encourage you to try get people to be open about
> things here - there's no particular shame in having 10% TLSv1.0
> sessions after all:-)
>
> >
> > Note: I put in "back end processing" because these are the folks that
> most
> > often have many connections to other business partners and so in some
> ways
> > have the most complex systems to deal with.
> >
> > Note #2:  This is aspirational!  I hope I can get all these people to
> > cooperate.  I will try at least to get some in each category.
> >
> >
> > I will ask them the following questions:
> >
> > 1.  How many applications do you have?  (This may end up being only the
> > mission critical ones as otherwise it may be too hard to obtain.)
>
> I'm not sure that's so interesting for this question. And I'm not
> sure that different people would count things as applications in
> the same way.
>
> > 2.   How many are using TLS and how many are still plain text?  (We will
> > disregard SSH and other such variants.)
>
> Again, that's not so interesting here.
>
> > 3.   What percent of clients are using a pre-TLS1.2 version?  (This will
> be
> > an estimation.
> I don't see why this needs to be estimated, this is kinda the key
> measurement needed and easy to measure. There should be no need for
> anyone to stick their thumb in the air for this:-)
>
> It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
> TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
> figures apply.
>
> And of course providing as much context as possible so that it's
> possible to understand the numbers and whether or not the numbers
> from different sources are based on the same or different kinds of
> measurement.
>
> >
> > 4.   Do you have an active project to migrate off of older versions of
> TLS?
>
> Sure.
>
> >
> > 5.   What do you estimate your percent of clients using pre-TLS1.2
> versions
> > to be next year?
>
> I 

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[David Benjamin]

On Mon, Jul 9, 2018 at 12:58 PM Eric Rescorla  wrote:

> On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla  wrote:
>
>> Thanks for writing this.
>>
>> I would be in favor of deprecating old versions of TLS prior to 1.2.
>> Firefox Telemetry shows that about 1% of our connections are TLS 1.1
>>
>
> This should be 1.0.
>
>
> (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
>>
>> This is probably a higher number than we'd be comfortable turning off
>> immediately, but it is probably worth starting the process.
>>
>
Metrics from Chrome report 0.43% of our connections are TLS 1.0 and 0.03%
of them are TLS 1.1, which is a similar situation. I too am in favor of
deprecating them and getting things started.

David

On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Stephen and I posted the draft below to see if the TLS working group
>>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
>>> been a recent drop off in usage for web applications due to the PCI
>>> Council recommendation to move off TLSv1.0, with a recommendation to
>>> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
>>> as a baseline.  Applications other than those using HTTP may not have
>>> had the same reduction in usage.  If you are responsible for services
>>> where you have a reasonable vantage point to gather and share
>>> statistics to assess usage further, that could be helpful for the
>>> discussion.  We've received some feedback that has been incorporated
>>> into the working draft and feelers in general have been positive.  It
>>> would be good to know if there are any show stoppers that have not
>>> been considered.
>>>
>>> https://github.com/sftcd/tls-oldversions-diediedie
>>>
>>> Thanks in advance,
>>> Kathleen
>>>
>>>
>>> -- Forwarded message --
>>> From:  
>>> Date: Mon, Jun 18, 2018 at 3:05 PM
>>> Subject: New Version Notification for
>>> draft-moriarty-tls-oldversions-diediedie-00.txt
>>> To: Stephen Farrell , Kathleen Moriarty
>>> 
>>>
>>>
>>>
>>> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
>>> has been successfully submitted by Stephen Farrell and posted to the
>>> IETF repository.
>>>
>>> Name:   draft-moriarty-tls-oldversions-diediedie
>>> Revision:   00
>>> Title:  Deprecating TLSv1.0 and TLSv1.1
>>> Document date:  2018-06-18
>>> Group:  Individual Submission
>>> Pages:  10
>>> URL:
>>>
>>> https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
>>> 
>>> Status:
>>>
>>> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
>>> Htmlized:
>>>
>>> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie
>>>
>>>
>>> Abstract:
>>>This document [if approved] formally deprecates Transport Layer
>>>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
>>>these documents to the historic state.  These versions lack support
>>>for current and recommended cipher suites, and various government and
>>>industry profiiles of applications using TLS now mandate avoiding
>>>these old TLS versions.  TLSv1.2 has been the recommended version for
>>>IETF protocols since 2008, providing sufficient time to transition
>>>away from older versions.  Products having to support older versions
>>>increase the attack surface unnecessarily and increase opportunities
>>>for misconfigurations.  Supporting these older versions also requires
>>>additional effort for library and product maintenance.
>>>
>>>This document updates the backward compatibility sections of TLS RFCs
>>>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
>>>document also updates RFC 7525.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Kathleen Moriarty]

Contributions with data are welcomed and encouraged.

Thank you,
Kathleen 

Sent from my mobile device

> On Jul 10, 2018, at 10:07 AM, Peter Gutmann  wrote:
> 
> nalini elkins  writes:
> 
>> It would be nice to see some of this reflected in the draft rather than only
>> statistics on browsers.   The real usage of these protocols is far more
>> complex.
> 
> +1.  It often seems that the only possible use for TLS that gets considered in
> these things is web browsers and web servers, or big-iron type servers in
> general.  There's a vast amount of TLS that never goes anywhere near a browser
> or server of this kind.  In particular, the assumptions that are no longer
> valid in this case are:
> 
> - CPU and memory is nearly unlimited and nearly free.
> 
> - Anything can be easily upgraded at the touch of a button.
> 
> - Everyone gets their certs from a commercial CA (that's present in a trust
>  database).
> 
> - People want the most full-featured, complex protocol possible.
> 
> - Users want the latest, trendiest algorithms at all times.
> 
> [Feel free to add more to this list, that's just the stuff that springs
> immediately to mind].
> 
> In the case of SCADA/embedded, pretty much the exact opposite of all of those
> points is the case (the last may be somewhat debatable, it's a reference to
> the fact that industry groups are very conservative and tend to stick with
> something that has what's regarded as good provenance).
> 
> Peter.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Kathleen Moriarty]

Hi Nalini,

I think it would be more useful to collect show stopper information.  Do they 
have systems or applications that cannot be upgraded as there is no upgrade 
path?  Do these systems or applications matter in terms of deprecation?  It may 
not matter if they are isolated or there is no external requirement around 
encryption.

I did hear from someone off-list that I think will submit a PR on the systems 
he can’t upgrade, but he also said they don’t matter and are not a show stopper.

Thank you,
Kathleen 

Sent from my mobile device

> On Jul 11, 2018, at 5:50 AM, Stephen Farrell  
> wrote:
> 
> 
> Hiya,
> 
>> On 11/07/18 06:45, nalini elkins wrote:
>> Stephen,
>> 
>>> I'd love to add more detail like that and/or more sections for other
>> protocols if folks have data to offer with references.
>> 
>> I believe that I can reach out to various people I know.   Please comment
>> if my methodology is acceptable and if you think this will be helpful.
> 
> It's not whether the methodology is acceptable to me or not
> but whether or not the references to the numbers are credible
> for readers:-)
> 
> A few comment below,
> 
>> 
>> I am thinking the following:
>> 
>> Location: U.S. / Canada (possibly U.K.)
>> 
>> -  3 banks (hopefully from the top 5)
>> -  3 large insurance companies  (includes back end processing)
>> -  3 U.S. federal government agencies
>> -  3 companies in the Wall Street / Stock brokerage sector (includes back
>> end processing)
>> -  3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.)
>> -  3 in the retail sector (Home Depot, Target, Lowes, et al)
> 
> Those are pretty small numbers unless they're interacting with
> a lot of TLS services. It'd be hard to know if they'd be
> representative of something or not if they're anonymised in the
> results. I'd encourage you to try get people to be open about
> things here - there's no particular shame in having 10% TLSv1.0
> sessions after all:-)
> 
>> 
>> Note: I put in "back end processing" because these are the folks that most
>> often have many connections to other business partners and so in some ways
>> have the most complex systems to deal with.
>> 
>> Note #2:  This is aspirational!  I hope I can get all these people to
>> cooperate.  I will try at least to get some in each category.
>> 
>> 
>> I will ask them the following questions:
>> 
>> 1.  How many applications do you have?  (This may end up being only the
>> mission critical ones as otherwise it may be too hard to obtain.)
> 
> I'm not sure that's so interesting for this question. And I'm not
> sure that different people would count things as applications in
> the same way.
> 
>> 2.   How many are using TLS and how many are still plain text?  (We will
>> disregard SSH and other such variants.)
> 
> Again, that's not so interesting here.
> 
>> 3.   What percent of clients are using a pre-TLS1.2 version?  (This will be
>> an estimation.
> I don't see why this needs to be estimated, this is kinda the key
> measurement needed and easy to measure. There should be no need for
> anyone to stick their thumb in the air for this:-)
> 
> It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
> TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
> figures apply.
> 
> And of course providing as much context as possible so that it's
> possible to understand the numbers and whether or not the numbers
> from different sources are based on the same or different kinds of
> measurement.
> 
>> 
>> 4.   Do you have an active project to migrate off of older versions of TLS?
> 
> Sure.
> 
>> 
>> 5.   What do you estimate your percent of clients using pre-TLS1.2 versions
>> to be next year?
> 
> I don't see how this'd be so useful. Aaking about the historic and
> current rates of change of use of the various protocol versions would
> be good though if people have that, but they may not.
> 
> S.
> 
>> 
>> 
>> Please let me know if this will be of use & if you have suggestions for
>> improvement.
>> 
>> Thanks,
>> Nalini
>> 
>> 
>> 
>> 
>> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell 
>> wrote:
>> 
>>> 
>>> Hi Nalini,
>>> 
 On 10/07/18 04:50, nalini elkins wrote:
 It would be nice to see some of this reflected in the draft rather than
 only statistics on browsers.   The real usage of these protocols is far
 more complex.
>>> 
>>> I didn't have time before the I-D cutoff but have since
>>> added a section on mail to the repo pre-01 version. (See
>>> [1] section 3.2.) I'd love to add more detail like that
>>> and/or more sections for other protocols if folks have
>>> data to offer with references.
>>> 
>>> Consistent with other folks' numbers sent to the list
>>> yesterday, (though based on a much smaller sat of data I
>>> guess;-) my data shows 10.6% use of TLSv1.0 when talking
>>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
>>> IP addresses that listen on port 25 (mail servers).
>>> 
>>> What I don't currently have is a rate of 

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Salz, Rich]

> I'm not sure that the fact that a lot of people are running downrev versions 
> means we shouldn't say that the IETF no longer considers that good.

I totally and strongly agree.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Eric Rescorla]

I'd like to distinguish between two different questions:

1. Whether or not the IETF should recommend that people stop using older
versions of TLS.
2. Whether or not vendors should stop accepting/supporting older versions
of TLS.

The former one of these is just exhorting people to stop, which people can
comply with or not. The latter has real impact, especially for something
like a browser where ou (and counterparties) just get involuntarily
upgraded.

In the latter situation, we need to be pretty sensitive to wide use to
avoid bricking people. In the former situation, however, part of the
purpose of the IETF deprecating these protocols is to tell people who
haven't gotten off that we think they should, and that's a judgement partly
driven by uses (otherwise you look silly) but not entirely so. Given that
there is a good alternative (i.e., TLS 1.2) that's straightforward to
deploy, I'm not sure that the fact that a lot of people are running downrev
versions means we shouldn't say that the IETF no longer considers that good.

-Ekr


On Wed, Jul 11, 2018 at 2:50 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 11/07/18 06:45, nalini elkins wrote:
> >  Stephen,
> >
> >> I'd love to add more detail like that and/or more sections for other
> > protocols if folks have data to offer with references.
> >
> > I believe that I can reach out to various people I know.   Please comment
> > if my methodology is acceptable and if you think this will be helpful.
>
> It's not whether the methodology is acceptable to me or not
> but whether or not the references to the numbers are credible
> for readers:-)
>
> A few comment below,
>
> >
> > I am thinking the following:
> >
> > Location: U.S. / Canada (possibly U.K.)
> >
> > -  3 banks (hopefully from the top 5)
> > -  3 large insurance companies  (includes back end processing)
> > -  3 U.S. federal government agencies
> > -  3 companies in the Wall Street / Stock brokerage sector (includes back
> > end processing)
> > -  3 large credit card / processors (ex. Visa, Discover, MasterCard,
> etc.)
> > -  3 in the retail sector (Home Depot, Target, Lowes, et al)
>
> Those are pretty small numbers unless they're interacting with
> a lot of TLS services. It'd be hard to know if they'd be
> representative of something or not if they're anonymised in the
> results. I'd encourage you to try get people to be open about
> things here - there's no particular shame in having 10% TLSv1.0
> sessions after all:-)
>
> >
> > Note: I put in "back end processing" because these are the folks that
> most
> > often have many connections to other business partners and so in some
> ways
> > have the most complex systems to deal with.
> >
> > Note #2:  This is aspirational!  I hope I can get all these people to
> > cooperate.  I will try at least to get some in each category.
> >
> >
> > I will ask them the following questions:
> >
> > 1.  How many applications do you have?  (This may end up being only the
> > mission critical ones as otherwise it may be too hard to obtain.)
>
> I'm not sure that's so interesting for this question. And I'm not
> sure that different people would count things as applications in
> the same way.
>
> > 2.   How many are using TLS and how many are still plain text?  (We will
> > disregard SSH and other such variants.)
>
> Again, that's not so interesting here.
>
> > 3.   What percent of clients are using a pre-TLS1.2 version?  (This will
> be
> > an estimation.
> I don't see why this needs to be estimated, this is kinda the key
> measurement needed and easy to measure. There should be no need for
> anyone to stick their thumb in the air for this:-)
>
> It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
> TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
> figures apply.
>
> And of course providing as much context as possible so that it's
> possible to understand the numbers and whether or not the numbers
> from different sources are based on the same or different kinds of
> measurement.
>
> >
> > 4.   Do you have an active project to migrate off of older versions of
> TLS?
>
> Sure.
>
> >
> > 5.   What do you estimate your percent of clients using pre-TLS1.2
> versions
> > to be next year?
>
> I don't see how this'd be so useful. Aaking about the historic and
> current rates of change of use of the various protocol versions would
> be good though if people have that, but they may not.
>
> S.
>
> >
> >
> > Please let me know if this will be of use & if you have suggestions for
> > improvement.
> >
> > Thanks,
> > Nalini
> >
> >
> >
> >
> > On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hi Nalini,
> >>
> >> On 10/07/18 04:50, nalini elkins wrote:
> >>> It would be nice to see some of this reflected in the draft rather than
> >>> only statistics on browsers.   The real usage of these protocols is far
> >>> more complex.
> >>
> >> I didn't have time before the I-D cutoff but have since
> >> 

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

On 11/07/18 06:45, nalini elkins wrote:
>  Stephen,
> 
>> I'd love to add more detail like that and/or more sections for other
> protocols if folks have data to offer with references.
> 
> I believe that I can reach out to various people I know.   Please comment
> if my methodology is acceptable and if you think this will be helpful.

It's not whether the methodology is acceptable to me or not
but whether or not the references to the numbers are credible
for readers:-)

A few comment below,

> 
> I am thinking the following:
> 
> Location: U.S. / Canada (possibly U.K.)
> 
> -  3 banks (hopefully from the top 5)
> -  3 large insurance companies  (includes back end processing)
> -  3 U.S. federal government agencies
> -  3 companies in the Wall Street / Stock brokerage sector (includes back
> end processing)
> -  3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.)
> -  3 in the retail sector (Home Depot, Target, Lowes, et al)

Those are pretty small numbers unless they're interacting with
a lot of TLS services. It'd be hard to know if they'd be
representative of something or not if they're anonymised in the
results. I'd encourage you to try get people to be open about
things here - there's no particular shame in having 10% TLSv1.0
sessions after all:-)

> 
> Note: I put in "back end processing" because these are the folks that most
> often have many connections to other business partners and so in some ways
> have the most complex systems to deal with.
> 
> Note #2:  This is aspirational!  I hope I can get all these people to
> cooperate.  I will try at least to get some in each category.
> 
> 
> I will ask them the following questions:
> 
> 1.  How many applications do you have?  (This may end up being only the
> mission critical ones as otherwise it may be too hard to obtain.)

I'm not sure that's so interesting for this question. And I'm not
sure that different people would count things as applications in
the same way.

> 2.   How many are using TLS and how many are still plain text?  (We will
> disregard SSH and other such variants.)

Again, that's not so interesting here.

> 3.   What percent of clients are using a pre-TLS1.2 version?  (This will be
> an estimation.
I don't see why this needs to be estimated, this is kinda the key
measurement needed and easy to measure. There should be no need for
anyone to stick their thumb in the air for this:-)

It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
figures apply.

And of course providing as much context as possible so that it's
possible to understand the numbers and whether or not the numbers
from different sources are based on the same or different kinds of
measurement.

> 
> 4.   Do you have an active project to migrate off of older versions of TLS?

Sure.

> 
> 5.   What do you estimate your percent of clients using pre-TLS1.2 versions
> to be next year?

I don't see how this'd be so useful. Aaking about the historic and
current rates of change of use of the various protocol versions would
be good though if people have that, but they may not.

S.

> 
> 
> Please let me know if this will be of use & if you have suggestions for
> improvement.
> 
> Thanks,
> Nalini
> 
> 
> 
> 
> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell 
> wrote:
> 
>>
>> Hi Nalini,
>>
>> On 10/07/18 04:50, nalini elkins wrote:
>>> It would be nice to see some of this reflected in the draft rather than
>>> only statistics on browsers.   The real usage of these protocols is far
>>> more complex.
>>
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
>> and/or more sections for other protocols if folks have
>> data to offer with references.
>>
>> Consistent with other folks' numbers sent to the list
>> yesterday, (though based on a much smaller sat of data I
>> guess;-) my data shows 10.6% use of TLSv1.0 when talking
>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
>> IP addresses that listen on port 25 (mail servers).
>>
>> What I don't currently have is a rate of change for that
>> figure. I think that rate of change is the important number
>> for figuring out what to do in the next while. E.g. The
>> WG might conclude that if the percentage of TLSv1.0 is
>> moving down nicely, we should be a bit patient. If it's
>> not moving at all, we can probably move now or in 5 years
>> without that being different. If we're not sure, then get
>> more data...
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast
>> er/draft-moriarty-tls-oldversions-diediedie.txt
>>
> 
> 
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[nalini elkins]

 Stephen,

> I'd love to add more detail like that and/or more sections for other
protocols if folks have data to offer with references.

I believe that I can reach out to various people I know.   Please comment
if my methodology is acceptable and if you think this will be helpful.

I am thinking the following:

Location: U.S. / Canada (possibly U.K.)

-  3 banks (hopefully from the top 5)
-  3 large insurance companies  (includes back end processing)
-  3 U.S. federal government agencies
-  3 companies in the Wall Street / Stock brokerage sector (includes back
end processing)
-  3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.)
-  3 in the retail sector (Home Depot, Target, Lowes, et al)

Note: I put in "back end processing" because these are the folks that most
often have many connections to other business partners and so in some ways
have the most complex systems to deal with.

Note #2:  This is aspirational!  I hope I can get all these people to
cooperate.  I will try at least to get some in each category.


I will ask them the following questions:

1.  How many applications do you have?  (This may end up being only the
mission critical ones as otherwise it may be too hard to obtain.)


2.   How many are using TLS and how many are still plain text?  (We will
disregard SSH and other such variants.)


3.   What percent of clients are using a pre-TLS1.2 version?  (This will be
an estimation.)


4.   Do you have an active project to migrate off of older versions of TLS?


5.   What do you estimate your percent of clients using pre-TLS1.2 versions
to be next year?


Please let me know if this will be of use & if you have suggestions for
improvement.

Thanks,
Nalini




On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell 
wrote:

>
> Hi Nalini,
>
> On 10/07/18 04:50, nalini elkins wrote:
> > It would be nice to see some of this reflected in the draft rather than
> > only statistics on browsers.   The real usage of these protocols is far
> > more complex.
>
> I didn't have time before the I-D cutoff but have since
> added a section on mail to the repo pre-01 version. (See
> [1] section 3.2.) I'd love to add more detail like that
> and/or more sections for other protocols if folks have
> data to offer with references.
>
> Consistent with other folks' numbers sent to the list
> yesterday, (though based on a much smaller sat of data I
> guess;-) my data shows 10.6% use of TLSv1.0 when talking
> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
> IP addresses that listen on port 25 (mail servers).
>
> What I don't currently have is a rate of change for that
> figure. I think that rate of change is the important number
> for figuring out what to do in the next while. E.g. The
> WG might conclude that if the percentage of TLSv1.0 is
> moving down nicely, we should be a bit patient. If it's
> not moving at all, we can probably move now or in 5 years
> without that being different. If we're not sure, then get
> more data...
>
> Cheers,
> S.
>
> [1]
> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast
> er/draft-moriarty-tls-oldversions-diediedie.txt
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hiya,

On 10/07/18 19:04, Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote:
> 
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
>> and/or more sections for other protocols if folks have
>> data to offer with references.
> 
> The numbers for MX hosts with working DANE TLSA records are:
> 
> 4337  TLS 1.2
>   63  TLS 1.0
>5  TLS 1.1

Thanks. I'll try add text on the above and other usable
numbers sent to the list to the repo version before we shoot
out a -01.

> These are early adopters of enhanced SMTP security, so one would
> expect to find modern software and an emphasis on security, and
> yet, for >1% of the MX hosts, their SMTP server libraries fail to
> negotiate TLS 1.2.  Presumably, the broader MTA population has a
> higher incidence of TLS 1.0-only servers.

Fair point.

Cheers,
S.


> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Viktor Dukhovni]

On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote:

> I didn't have time before the I-D cutoff but have since
> added a section on mail to the repo pre-01 version. (See
> [1] section 3.2.) I'd love to add more detail like that
> and/or more sections for other protocols if folks have
> data to offer with references.

The numbers for MX hosts with working DANE TLSA records are:

4337  TLS 1.2
  63  TLS 1.0
   5  TLS 1.1

These are early adopters of enhanced SMTP security, so one would
expect to find modern software and an emphasis on security, and
yet, for >1% of the MX hosts, their SMTP server libraries fail to
negotiate TLS 1.2.  Presumably, the broader MTA population has a
higher incidence of TLS 1.0-only servers.

-- 
Viktor.

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Peter Gutmann]

nalini elkins  writes:

>It would be nice to see some of this reflected in the draft rather than only
>statistics on browsers.   The real usage of these protocols is far more
>complex.

+1.  It often seems that the only possible use for TLS that gets considered in
these things is web browsers and web servers, or big-iron type servers in
general.  There's a vast amount of TLS that never goes anywhere near a browser
or server of this kind.  In particular, the assumptions that are no longer
valid in this case are:

- CPU and memory is nearly unlimited and nearly free.

- Anything can be easily upgraded at the touch of a button.

- Everyone gets their certs from a commercial CA (that's present in a trust
  database).

- People want the most full-featured, complex protocol possible.

- Users want the latest, trendiest algorithms at all times.

[Feel free to add more to this list, that's just the stuff that springs
 immediately to mind].

In the case of SCADA/embedded, pretty much the exact opposite of all of those
points is the case (the last may be somewhat debatable, it's a reference to
the fact that industry groups are very conservative and tend to stick with
something that has what's regarded as good provenance).

Peter.

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Stephen Farrell]

Hi Nalini,

On 10/07/18 04:50, nalini elkins wrote:
> It would be nice to see some of this reflected in the draft rather than
> only statistics on browsers.   The real usage of these protocols is far
> more complex.

I didn't have time before the I-D cutoff but have since
added a section on mail to the repo pre-01 version. (See
[1] section 3.2.) I'd love to add more detail like that
and/or more sections for other protocols if folks have
data to offer with references.

Consistent with other folks' numbers sent to the list
yesterday, (though based on a much smaller sat of data I
guess;-) my data shows 10.6% use of TLSv1.0 when talking
SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
IP addresses that listen on port 25 (mail servers).

What I don't currently have is a rate of change for that
figure. I think that rate of change is the important number
for figuring out what to do in the next while. E.g. The
WG might conclude that if the percentage of TLSv1.0 is
moving down nicely, we should be a bit patient. If it's
not moving at all, we can probably move now or in 5 years
without that being different. If we're not sure, then get
more data...

Cheers,
S.

[1]
https://github.com/sftcd/tls-oldversions-diediedie/blob/master/draft-moriarty-tls-oldversions-diediedie.txt


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[nalini elkins]

>On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the
time on the client side (this includes non-browser connections from all
sorts of apps, some hard-coding TLS versions), and TLS 1.1 accounts for
~0.3% of client >connections.  Windows server negotiates TLS 1.0 ~1.5% of
the time (all server apps, not just IIS), and the use of TLS 1.1 is
negligible.



>Therefore, we cannot disable TLS 1.0 by default in Windows just yet, but
will keep looking at the telemetry. If PCI/NIST/diediedie RFC make a
difference, I’ll be happy to reduce the set of enabled-by-default TLS
versions.



While I support the move to more secure versions of TLS, I would say that
in the U.S. at least, is that people are trying as hard as they can to get
current.  It is not that easy.  My data points are the Fortune 500 and
equivalent sized

government agencies, including city and county governments, even large
school districts such as Los Angeles Unified.   For at least the last two
to four years, quite a few of the people that I know have been trying to
get upgraded to TLS1.2 on their own - with no incentive needed.


A while back, I was talking to someone I know about the PCI mandate for
June 30th.   These guys run quite a large network with millions of clients
coming in via business partner and other networks.  By the time, they get
to his applications, he really has no idea what the actual IP address of
the end user is and how to reach out to them to get them to upgrade
whatever client software they have that is not current.  He has a number of
his staff devoted to doing just this.


The endpoints are not just running browsers.  They may have Telnet, FTP,
SMTP, MQSeries or any one of a thousand different applications.  Each with
their own client software which has to be upgraded individually.


Keeping endpoints and applications patched and current takes a huge amount
of effort - maybe the bulk of the effort - spent by staff at enterprises.
 The manager of the above site said to me that he knows the PCI date is
June 30 to get off of earlier versions of TLS but he said, "You know,
Nalini, we may not make it."   Those guys are very smart.  I have known
them for many years


My guess would be that it is in the 10 - 20% range for clients using
versions pre-TLS1.2.

It would be nice to see some of this reflected in the draft rather than
only statistics on browsers.   The real usage of these protocols is far
more complex.


Nalini




On Mon, Jul 9, 2018 at 11:30 PM, Andrei Popov <
Andrei.Popov=40microsoft@dmarc.ietf.org> wrote:

> On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the
> time on the client side (this includes non-browser connections from all
> sorts of apps, some hard-coding TLS versions), and TLS 1.1 accounts for
> ~0.3% of client connections.
>
> Windows server negotiates TLS 1.0 ~1.5% of the time (all server apps, not
> just IIS), and the use of TLS 1.1 is negligible.
>
>
>
> Therefore, we cannot disable TLS 1.0 by default in Windows just yet, but
> will keep looking at the telemetry. If PCI/NIST/diediedie RFC make a
> difference, I’ll be happy to reduce the set of enabled-by-default TLS
> versions.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS  *On Behalf Of * Eric Rescorla
> *Sent:* Monday, July 9, 2018 9:57 AM
> *To:* Kathleen Moriarty 
> *Cc:*  
> *Subject:* Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-
> oldversions-diediedie-00.txt
>
>
>
>
>
>
>
> On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla  wrote:
>
> Thanks for writing this.
>
>
>
> I would be in favor of deprecating old versions of TLS prior to 1.2.
> Firefox Telemetry shows that about 1% of our connections are TLS 1.1
>
>
>
> This should be 1.0.
>
>
>
>
>
> (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
>
>
>
> This is probably a higher number than we'd be comfortable turning off
> immediately, but it is probably worth starting the process.
>
>
>
> -Ekr
>
>
>
>
>
> On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
>
> Hello,
>
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off TLSv1.0, with a recommendation to
> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
> as a baseline.  Applications other than those using HTTP may not have
> had the same reduction in usage.  If you are responsible for services
> where you have a reasonable vantage point to gather and share
> statistics to assess usage further, that could be helpful for the

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Martin Thomson]

I want to see these disappear, but I am guessing that there is still
some time before many products can make the move.  For websites, like
the ones mentioned in the draft, that time is already here.  As a site
operator, you do not want to talk to a browser that doesn't talk TLS
1.2.

Is there any reason why we wouldn't also consider deprecating cipher
suites we don't like?  For instance, RFC 5246 mandates the
implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably
agree isn't ideal for several reasons.  The ECDHE suites with AES-GCM
are widely available, perhaps widely enough that we might consider a
stronger move and update 5246 to modern suites.

Our numbers for AES-CBC are not anywhere near as low as TLS <1.2, but
they are definitely trending in the right direction.  3DES still
exists too, which is a little sad, but there you are.
On Tue, Jul 10, 2018 at 2:42 AM Kathleen Moriarty
 wrote:
>
> Hello,
>
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off TLSv1.0, with a recommendation to
> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
> as a baseline.  Applications other than those using HTTP may not have
> had the same reduction in usage.  If you are responsible for services
> where you have a reasonable vantage point to gather and share
> statistics to assess usage further, that could be helpful for the
> discussion.  We've received some feedback that has been incorporated
> into the working draft and feelers in general have been positive.  It
> would be good to know if there are any show stoppers that have not
> been considered.
>
> https://github.com/sftcd/tls-oldversions-diediedie
>
> Thanks in advance,
> Kathleen
>
>
> -- Forwarded message --
> From:  
> Date: Mon, Jun 18, 2018 at 3:05 PM
> Subject: New Version Notification for
> draft-moriarty-tls-oldversions-diediedie-00.txt
> To: Stephen Farrell , Kathleen Moriarty
> 
>
>
>
> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
> has been successfully submitted by Stephen Farrell and posted to the
> IETF repository.
>
> Name:   draft-moriarty-tls-oldversions-diediedie
> Revision:   00
> Title:  Deprecating TLSv1.0 and TLSv1.1
> Document date:  2018-06-18
> Group:  Individual Submission
> Pages:  10
> URL:
> https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
> Htmlized:
> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie
>
>
> Abstract:
>This document [if approved] formally deprecates Transport Layer
>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
>these documents to the historic state.  These versions lack support
>for current and recommended cipher suites, and various government and
>industry profiiles of applications using TLS now mandate avoiding
>these old TLS versions.  TLSv1.2 has been the recommended version for
>IETF protocols since 2008, providing sufficient time to transition
>away from older versions.  Products having to support older versions
>increase the attack surface unnecessarily and increase opportunities
>for misconfigurations.  Supporting these older versions also requires
>additional effort for library and product maintenance.
>
>This document updates the backward compatibility sections of TLS RFCs
>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
>document also updates RFC 7525.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --
>
> Best regards,
> Kathleen
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Martin Rex]

Andrei Popov  wrote:
>
> On the recent Windows versions, TLS 1.0 is negotiated more than 10%
> of the time on the client side (this includes non-browser connections
> from all sorts of apps, some hard-coding TLS versions),
> and TLS 1.1 accounts for ~0.3% of client connections.

"On recent Windows versions" sounds like figure might not account
for Windows 7 and Windows Server 2008R2, about half of the installed
base of Windows, and where the numbers are likely *MUCH* higher.

When troubleshooting TLS handshake failures, I sometimes trying
alternative SSL/TLS clients on customer machines through remote support,
and it seems when I run this command on a Windows 2012R2 server:

powershell "$web=New-Object System.Net.WebClient ; 
$web.DownloadString('https://www.example.com/')" 2>&1

it connects with TLSv1.0 only, and this is a client-side limitation.

To make it use TLSv1.2, I would have to use

powershell "[Net.ServicePointManager]::SecurityProtocol = 
[Net.SecurityProtocolType]::Tls12 ; $web=New-Object System.Net.WebClient ; 
$web.DownloadString('https://www.example.com/')" 2>&1

i.e. explicit opt-in.


I already have a long list of stuff that uses TLSv1.0 for outgoing
communication by default, and that list is constantly growing, and that
is not just stuff running with JavaSE 1.6 or JavaSE 1.7.
Btw. lots of J2EE Servers are still on JavaSE 1.6, without the
non-public TLSv1.2-capable update.


We also had customer incidents about hardware stuff, they called it "RF Gun",
probably some RFID scanner, that seems to be limited to TLSv1.0 and
TLSv1.0 cipher suites (either 3DES-EDE-CBC-SHA or RC4-128).


I would really hate it to see the IETF enter the "planned/forced obsolence"
market, growing the dumpsters of electronic equipment that would still work
just fine, but has to be retired for the sole purpose of economic growth.


-Martin

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Eric Mill]

If we're looking for precedent and support, the Canadian government
recently (like in the last week or two) issued a policy requiring TLS 1.0
and 1.1 be disabled:

https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html

It's effective immediately for new services, and has a deadline of
September 30, 2019 for existing services.

-- Eric

On Mon, Jul 9, 2018 at 3:02 PM Loganaden Velvindron 
wrote:

> On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla  wrote:
> > Thanks for writing this.
> >
> > I would be in favor of deprecating old versions of TLS prior to 1.2.
> Firefox
> > Telemetry shows that about 1% of our connections are TLS 1.1 (on the same
> > data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
> >
> > This is probably a higher number than we'd be comfortable turning off
> > immediately, but it is probably worth starting the process.
> >
>
> I'm also in favour. Many banks/instituion in developing countries are
> moving to deprecate tls v1.0 and tls v1.1.
>
> As I commented on github:
> SSLpulse shows how many top websites support tls 1.2 (92.8%) and this
> number is increasing (0.5%):
>
> https://www.ssllabs.com/ssl-pulse/
>
> KeyCDN and digicert have also announced their intentions to deprecate
> tls 1.0 and tls 1.1.
>
>
> https://github.com/sftcd/tls-oldversions-diediedie/commit/a0d6c160d922bd7f52a917884823114c90932291
>
>
>
> > -Ekr
> >
> >
> > On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty
> >  wrote:
> >>
> >> Hello,
> >>
> >> Stephen and I posted the draft below to see if the TLS working group
> >> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> >> been a recent drop off in usage for web applications due to the PCI
> >> Council recommendation to move off TLSv1.0, with a recommendation to
> >> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
> >> as a baseline.  Applications other than those using HTTP may not have
> >> had the same reduction in usage.  If you are responsible for services
> >> where you have a reasonable vantage point to gather and share
> >> statistics to assess usage further, that could be helpful for the
> >> discussion.  We've received some feedback that has been incorporated
> >> into the working draft and feelers in general have been positive.  It
> >> would be good to know if there are any show stoppers that have not
> >> been considered.
> >>
> >> https://github.com/sftcd/tls-oldversions-diediedie
> >>
> >> Thanks in advance,
> >> Kathleen
> >>
> >>
> >> -- Forwarded message --
> >> From:  
> >> Date: Mon, Jun 18, 2018 at 3:05 PM
> >> Subject: New Version Notification for
> >> draft-moriarty-tls-oldversions-diediedie-00.txt
> >> To: Stephen Farrell , Kathleen Moriarty
> >> 
> >>
> >>
> >>
> >> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
> >> has been successfully submitted by Stephen Farrell and posted to the
> >> IETF repository.
> >>
> >> Name:   draft-moriarty-tls-oldversions-diediedie
> >> Revision:   00
> >> Title:  Deprecating TLSv1.0 and TLSv1.1
> >> Document date:  2018-06-18
> >> Group:  Individual Submission
> >> Pages:  10
> >> URL:
> >>
> >> https://www.ietf.
> .org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
> >>
> >> Status:
> >>
> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
> >> Htmlized:
> >> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
> >> Htmlized:
> >>
> >>
> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie
> >>
> >>
> >> Abstract:
> >>This document [if approved] formally deprecates Transport Layer
> >>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
> >>these documents to the historic state.  These versions lack support
> >>for current and recommended cipher suites, and various government and
> >>industry profiiles of applications using TLS now mandate avoiding
> >>these old TLS versions.  TLSv1.2 has been the recommended version for
> >>IETF protocols since 2008, providing sufficient time to transition
> >>away from older versions.  Products having to support older versions
> >>increase the attack surface unnecessarily and increase opportunities
> >>for misconfigurations.  Supporting these older versions also requires
> >>additional effort for library and product maintenance.
> >>
> >>This document updates the backward compatibility sections of TLS RFCs
> >>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
> >>document also updates RFC 7525.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >>
> >> 

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Loganaden Velvindron]

On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla  wrote:
> Thanks for writing this.
>
> I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox
> Telemetry shows that about 1% of our connections are TLS 1.1 (on the same
> data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
>
> This is probably a higher number than we'd be comfortable turning off
> immediately, but it is probably worth starting the process.
>

I'm also in favour. Many banks/instituion in developing countries are
moving to deprecate tls v1.0 and tls v1.1.

As I commented on github:
SSLpulse shows how many top websites support tls 1.2 (92.8%) and this
number is increasing (0.5%):

https://www.ssllabs.com/ssl-pulse/

KeyCDN and digicert have also announced their intentions to deprecate
tls 1.0 and tls 1.1.

https://github.com/sftcd/tls-oldversions-diediedie/commit/a0d6c160d922bd7f52a917884823114c90932291



> -Ekr
>
>
> On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty
>  wrote:
>>
>> Hello,
>>
>> Stephen and I posted the draft below to see if the TLS working group
>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
>> been a recent drop off in usage for web applications due to the PCI
>> Council recommendation to move off TLSv1.0, with a recommendation to
>> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
>> as a baseline.  Applications other than those using HTTP may not have
>> had the same reduction in usage.  If you are responsible for services
>> where you have a reasonable vantage point to gather and share
>> statistics to assess usage further, that could be helpful for the
>> discussion.  We've received some feedback that has been incorporated
>> into the working draft and feelers in general have been positive.  It
>> would be good to know if there are any show stoppers that have not
>> been considered.
>>
>> https://github.com/sftcd/tls-oldversions-diediedie
>>
>> Thanks in advance,
>> Kathleen
>>
>>
>> -- Forwarded message --
>> From:  
>> Date: Mon, Jun 18, 2018 at 3:05 PM
>> Subject: New Version Notification for
>> draft-moriarty-tls-oldversions-diediedie-00.txt
>> To: Stephen Farrell , Kathleen Moriarty
>> 
>>
>>
>>
>> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
>> has been successfully submitted by Stephen Farrell and posted to the
>> IETF repository.
>>
>> Name:   draft-moriarty-tls-oldversions-diediedie
>> Revision:   00
>> Title:  Deprecating TLSv1.0 and TLSv1.1
>> Document date:  2018-06-18
>> Group:  Individual Submission
>> Pages:  10
>> URL:
>>
>> https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
>>
>> Status:
>> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
>> Htmlized:
>> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
>> Htmlized:
>>
>> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie
>>
>>
>> Abstract:
>>This document [if approved] formally deprecates Transport Layer
>>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
>>these documents to the historic state.  These versions lack support
>>for current and recommended cipher suites, and various government and
>>industry profiiles of applications using TLS now mandate avoiding
>>these old TLS versions.  TLSv1.2 has been the recommended version for
>>IETF protocols since 2008, providing sufficient time to transition
>>away from older versions.  Products having to support older versions
>>increase the attack surface unnecessarily and increase opportunities
>>for misconfigurations.  Supporting these older versions also requires
>>additional effort for library and product maintenance.
>>
>>This document updates the backward compatibility sections of TLS RFCs
>>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
>>document also updates RFC 7525.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Salz, Rich]

Without quoting any specific numbers, I share Alessandro's support for this, 
while also emphasizing that it will be quite some time before my employer stops 
supporting those versions.


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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Salz, Rich]

FWIW, The next release of OpenSSL is an LTS release and will be supported for 
five years.  It disables SSLv3 by default, but does enable TLS1.0 and TLS1.1 by 
default.  (It also includes TLS1.3, nudge nudge RFC editor queue.)



On 7/9/18, 12:42 PM, "Kathleen Moriarty"  
wrote:

Hello,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
as a baseline.  Applications other than those using HTTP may not have
had the same reduction in usage.  If you are responsible for services
where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.  We've received some feedback that has been incorporated
into the working draft and feelers in general have been positive.  It
would be good to know if there are any show stoppers that have not
been considered.

https://github.com/sftcd/tls-oldversions-diediedie

Thanks in advance,
Kathleen


-- Forwarded message --
From:  
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell , Kathleen Moriarty




A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:   draft-moriarty-tls-oldversions-diediedie
Revision:   00
Title:  Deprecating TLSv1.0 and TLSv1.1
Document date:  2018-06-18
Group:  Individual Submission
Pages:  10
URL:

https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
Status:
https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
Htmlized:
https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
Htmlized:

https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie


Abstract:
   This document [if approved] formally deprecates Transport Layer
   Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
   these documents to the historic state.  These versions lack support
   for current and recommended cipher suites, and various government and
   industry profiiles of applications using TLS now mandate avoiding
   these old TLS versions.  TLSv1.2 has been the recommended version for
   IETF protocols since 2008, providing sufficient time to transition
   away from older versions.  Products having to support older versions
   increase the attack surface unnecessarily and increase opportunities
   for misconfigurations.  Supporting these older versions also requires
   additional effort for library and product maintenance.

   This document updates the backward compatibility sections of TLS RFCs
   [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
   document also updates RFC 7525.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



-- 

Best regards,
Kathleen

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


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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Alessandro Ghedini]

On Mon, Jul 09, 2018 at 12:40:54PM -0400, Kathleen Moriarty wrote:
> Hello,
> 
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off TLSv1.0, with a recommendation to
> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
> as a baseline.  Applications other than those using HTTP may not have
> had the same reduction in usage.  If you are responsible for services
> where you have a reasonable vantage point to gather and share
> statistics to assess usage further, that could be helpful for the
> discussion.  We've received some feedback that has been incorporated
> into the working draft and feelers in general have been positive.  It
> would be good to know if there are any show stoppers that have not
> been considered.
> 
> https://github.com/sftcd/tls-oldversions-diediedie

I'm very much in favour of deprecating pre-TLSv1.2 versions, and this seems
like a good time to start.

As far as usage goes, it's still quite significant, at least as far as
Cloudflare is concerned. See the chart from a couple of months ago at:
https://blog.cloudflare.com/you-get-tls-1-3-you-get-tls-1-3-everyone-gets-tls-1-3/

Particularly for TLSv1.0, which is still at ~10% of all TLS connections we see,
while TLSv1.1 is at ~0.2%. Given this it's unlikely we (Cloudflare) will be
able to disable them by default any time soon, but we might be able to
understand the situation better once we do a more thorough analysis.

Cheers

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Andrei Popov]

On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the time 
on the client side (this includes non-browser connections from all sorts of 
apps, some hard-coding TLS versions), and TLS 1.1 accounts for ~0.3% of client 
connections.
Windows server negotiates TLS 1.0 ~1.5% of the time (all server apps, not just 
IIS), and the use of TLS 1.1 is negligible.

Therefore, we cannot disable TLS 1.0 by default in Windows just yet, but will 
keep looking at the telemetry. If PCI/NIST/diediedie RFC make a difference, 
I’ll be happy to reduce the set of enabled-by-default TLS versions.

Cheers,

Andrei

From: TLS  On Behalf Of Eric Rescorla
Sent: Monday, July 9, 2018 9:57 AM
To: Kathleen Moriarty 
Cc:  
Subject: Re: [TLS] Fwd: New Version Notification for 
draft-moriarty-tls-oldversions-diediedie-00.txt



On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Thanks for writing this.

I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox 
Telemetry shows that about 1% of our connections are TLS 1.1

This should be 1.0.


(on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.

This is probably a higher number than we'd be comfortable turning off 
immediately, but it is probably worth starting the process.

-Ekr


On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>> 
wrote:

Hello,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
as a baseline.  Applications other than those using HTTP may not have
had the same reduction in usage.  If you are responsible for services
where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.  We've received some feedback that has been incorporated
into the working draft and feelers in general have been positive.  It
would be good to know if there are any show stoppers that have not
been considered.

https://github.com/sftcd/tls-oldversions-diediedie<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsftcd%2Ftls-oldversions-diediedie=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215001514=6JSQZe93nWnAELvOgG3KyIcPopQleMDtNF6v8LWFXWU%3D=0>

Thanks in advance,
Kathleen


-- Forwarded message --
From:  mailto:internet-dra...@ietf.org>>
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>>, Kathleen Moriarty
mailto:kathleen.moriarty.i...@gmail.com>>



A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:   draft-moriarty-tls-oldversions-diediedie
Revision:   00
Title:  Deprecating TLSv1.0 and TLSv1.1
Document date:  2018-06-18
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-moriarty-tls-oldversions-diediedie-00.txt=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518=%2BBRGmMbf7r4mXoyWqHmT6kgNjHw7Drh7ldDceG5gqfQ%3D=0>
Status:
https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-moriarty-tls-oldversions-diediedie%2F=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518=Qge2nvcx8fz105Uux1rl1eM2yHiI7zbvxA8Pvps10z8%3D=0>
Htmlized:
https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-moriarty-tls-oldversions-diediedie-00=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535=Bz6FrvviPoSIxkB83boGxcOxVg2NvrqS3A1bUinNodc%3D=0>
Htmlized:
https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-moriarty-tls-oldversions-diediedie=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535=M1O48y

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Eric Rescorla]

On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla  wrote:

> Thanks for writing this.
>
> I would be in favor of deprecating old versions of TLS prior to 1.2.
> Firefox Telemetry shows that about 1% of our connections are TLS 1.1
>

This should be 1.0.


(on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
>
> This is probably a higher number than we'd be comfortable turning off
> immediately, but it is probably worth starting the process.
>
> -Ekr
>
>
> On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
>
>> Hello,
>>
>> Stephen and I posted the draft below to see if the TLS working group
>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
>> been a recent drop off in usage for web applications due to the PCI
>> Council recommendation to move off TLSv1.0, with a recommendation to
>> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
>> as a baseline.  Applications other than those using HTTP may not have
>> had the same reduction in usage.  If you are responsible for services
>> where you have a reasonable vantage point to gather and share
>> statistics to assess usage further, that could be helpful for the
>> discussion.  We've received some feedback that has been incorporated
>> into the working draft and feelers in general have been positive.  It
>> would be good to know if there are any show stoppers that have not
>> been considered.
>>
>> https://github.com/sftcd/tls-oldversions-diediedie
>>
>> Thanks in advance,
>> Kathleen
>>
>>
>> -- Forwarded message --
>> From:  
>> Date: Mon, Jun 18, 2018 at 3:05 PM
>> Subject: New Version Notification for
>> draft-moriarty-tls-oldversions-diediedie-00.txt
>> To: Stephen Farrell , Kathleen Moriarty
>> 
>>
>>
>>
>> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
>> has been successfully submitted by Stephen Farrell and posted to the
>> IETF repository.
>>
>> Name:   draft-moriarty-tls-oldversions-diediedie
>> Revision:   00
>> Title:  Deprecating TLSv1.0 and TLSv1.1
>> Document date:  2018-06-18
>> Group:  Individual Submission
>> Pages:  10
>> URL:
>> https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldv
>> ersions-diediedie-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversi
>> ons-diediedie/
>> Htmlized:
>> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-old
>> versions-diediedie
>>
>>
>> Abstract:
>>This document [if approved] formally deprecates Transport Layer
>>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
>>these documents to the historic state.  These versions lack support
>>for current and recommended cipher suites, and various government and
>>industry profiiles of applications using TLS now mandate avoiding
>>these old TLS versions.  TLSv1.2 has been the recommended version for
>>IETF protocols since 2008, providing sufficient time to transition
>>away from older versions.  Products having to support older versions
>>increase the attack surface unnecessarily and increase opportunities
>>for misconfigurations.  Supporting these older versions also requires
>>additional effort for library and product maintenance.
>>
>>This document updates the backward compatibility sections of TLS RFCs
>>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
>>document also updates RFC 7525.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Eric Rescorla]

Thanks for writing this.

I would be in favor of deprecating old versions of TLS prior to 1.2.
Firefox Telemetry shows that about 1% of our connections are TLS 1.1 (on
the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.

This is probably a higher number than we'd be comfortable turning off
immediately, but it is probably worth starting the process.

-Ekr


On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hello,
>
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off TLSv1.0, with a recommendation to
> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
> as a baseline.  Applications other than those using HTTP may not have
> had the same reduction in usage.  If you are responsible for services
> where you have a reasonable vantage point to gather and share
> statistics to assess usage further, that could be helpful for the
> discussion.  We've received some feedback that has been incorporated
> into the working draft and feelers in general have been positive.  It
> would be good to know if there are any show stoppers that have not
> been considered.
>
> https://github.com/sftcd/tls-oldversions-diediedie
>
> Thanks in advance,
> Kathleen
>
>
> -- Forwarded message --
> From:  
> Date: Mon, Jun 18, 2018 at 3:05 PM
> Subject: New Version Notification for
> draft-moriarty-tls-oldversions-diediedie-00.txt
> To: Stephen Farrell , Kathleen Moriarty
> 
>
>
>
> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
> has been successfully submitted by Stephen Farrell and posted to the
> IETF repository.
>
> Name:   draft-moriarty-tls-oldversions-diediedie
> Revision:   00
> Title:  Deprecating TLSv1.0 and TLSv1.1
> Document date:  2018-06-18
> Group:  Individual Submission
> Pages:  10
> URL:
> https://www.ietf.org/internet-drafts/draft-moriarty-tls-
> oldversions-diediedie-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
> Htmlized:
> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-
> oldversions-diediedie
>
>
> Abstract:
>This document [if approved] formally deprecates Transport Layer
>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
>these documents to the historic state.  These versions lack support
>for current and recommended cipher suites, and various government and
>industry profiiles of applications using TLS now mandate avoiding
>these old TLS versions.  TLSv1.2 has been the recommended version for
>IETF protocols since 2008, providing sufficient time to transition
>away from older versions.  Products having to support older versions
>increase the attack surface unnecessarily and increase opportunities
>for misconfigurations.  Supporting these older versions also requires
>additional effort for library and product maintenance.
>
>This document updates the backward compatibility sections of TLS RFCs
>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
>document also updates RFC 7525.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --
>
> Best regards,
> Kathleen
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls