Re: [TLS] TLS@IETF102 agenda

[Martin Thomson]

Given the volume of discussion on the list, I assume that the
deprecated TLS 1.*<1.2 discussion is for the purpose of an
announcement only.  There are things on the agenda that I (personally)
would prefer to see set aside for more time on that topic.  For
instance, we've had very little list activity on delegated
credentials.
On Thu, Jul 12, 2018 at 3:28 AM Sean Turner  wrote:
>
> A revised agenda has been posted.
>
> spt
>
> > On Jul 10, 2018, at 12:15, Sean Turner  wrote:
> >
> > All,
> >
> > The agenda has been posted:
> > https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02
> >
> > Note that we have two sessions:
> >
> >   tls Session 1 (2:00 requested)
> >   Monday, 16 July 2018, Afternoon Session I 1330-1530
> >   Room Name: Place du Canada size: 300
> >   -
> >   tls Session 2 (1:00 requested)
> >   Thursday, 19 July 2018, Afternoon Session III 1810-1910
> >   Room Name: Laurier size: 250
> >   -
> >
> > spt
>
> ___
> 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

[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] TLS@IETF102 agenda

[Sean Turner]

A revised agenda has been posted.

spt

> On Jul 10, 2018, at 12:15, Sean Turner  wrote:
> 
> All,
> 
> The agenda has been posted:
> https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02
> 
> Note that we have two sessions:
> 
>   tls Session 1 (2:00 requested)
>   Monday, 16 July 2018, Afternoon Session I 1330-1530
>   Room Name: Place du Canada size: 300
>   -
>   tls Session 2 (1:00 requested)
>   Thursday, 19 July 2018, Afternoon Session III 1810-1910
>   Room Name: Laurier size: 250
>   -
> 
> spt

___
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] [CAUTION] Re: Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Kathleen Moriarty]

Sent from my mobile device

> On Jul 10, 2018, at 4:31 PM, Martin Rex  wrote:
> 
> m...@sap.com (Martin Rex) wrote:
>> 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.
> 
> 
> btw. I checked this on a Windows 10 (1709) machine, and it's powershell also
> tries connecting with TLSv1.0 only.
> 
> To me, it looks more like 100% of the Microsoft Windows installed
> base not being ready for a TLSv1.2-only world.
> 
Martin,

Do you want to add a PR with this unless further verification is needed?

Thank you,
Kathleen 

> 
> -Martin
> 
> ___
> 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]

> 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] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)

[Hubert Kario]

On Wednesday, 11 July 2018 06:57:59 CEST Peter Gutmann wrote:
> Hubert Kario  writes:
> >defeating two hashes, when both use use the Merkle-Damgård construction, is
> >not much harder than breaking just one of them (increase of work factor
> >less than 2)
> 
> "In theory there is no difference between theory and practice.  In practice
> there is".
> 
> I'm aware of this long-standing theoretical weakness around multicollisions.
> I'm just as aware that in the fifteen-odd years since the Joux paper,
> no-one has ever managed to demonstrate an even remotely practical attack on
> dual hashes, despite the hugely tempting target of all of SSL/TLS being
> there as a reward.

2^77 is a rather high barrier of entry just to prove expected result – I'm not 
surprised about lack of practical attack at all.

Nobody has disproved the conclusion of that paper either, so we don't have the 
luxury of ignoring it.

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

[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