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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 13 July 2018 13:26 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B054130934 for <tls@ietfa.amsl.com>; Fri, 13 Jul 2018 06:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MozXvWgw5JqP for <tls@ietfa.amsl.com>; Fri, 13 Jul 2018 06:26:00 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C252B126BED for <tls@ietf.org>; Fri, 13 Jul 2018 06:25:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BACB6BE4C; Fri, 13 Jul 2018 14:25:54 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quLYJGC3y8Pp; Fri, 13 Jul 2018 14:25:54 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F0FCBE38; Fri, 13 Jul 2018 14:25:53 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1531488354; bh=y3aGYhKCv6kTA206N08uFWKZuX5P38NStcnGbeTwBp8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Rdvgfb2dAdw4IuIlW+/FYhHpQhJjho4yscUGmMdjGW9zYxc2IsdOB8LPHt51XjbPM 4E23nrLVGJi3iGzD5sl7e/MuuU5jo92HEepAgsa3ttGZx+eJi9xADp3s2KKb1s0CTH +lgK0VJz3rmcuhpg4q+Rp6qI7TR6BPYZRBARvmZ0=
To: nalini elkins <nalini.elkins@e-dco.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <CAHbuEH5J-F2cKag02Vx416jsy1N6XZOju28H99WAt71Pc5optg@mail.gmail.com> <CABcZeBN4RPt_=zu-PTPeaYbQ4KxC8DAf=a7359pZDjYavpxecw@mail.gmail.com> <CABcZeBMzweULuOfxe_Dp7n6M7Lt77_1Qq92=KzfmuBeShUSCDQ@mail.gmail.com> <CY4PR21MB0774BE80A4424D41D0C8C4138C440@CY4PR21MB0774.namprd21.prod.outlook.com> <CAPsNn2U-WqPM-Tqun4NQkhy+ctpkdjkXj_dFurChKDB3f=WqRA@mail.gmail.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> <CAPsNn2UyQMEnS7y-Vgpt7j7c_z38OyhPgguvD7m54yVT013u6g@mail.gmail.com> <e669c670-fa21-4df2-4098-4e0eb218f4b5@cs.tcd.ie> <CAPsNn2VoZqfEyviHr8wivHv2iACsySb--E1ogzxJ9v7FGTdM7Q@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <91231fb5-8d5a-c825-8ac7-dd34d46db746@cs.tcd.ie>
Date: Fri, 13 Jul 2018 14:25:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAPsNn2VoZqfEyviHr8wivHv2iACsySb--E1ogzxJ9v7FGTdM7Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MIPZJVicCfevS13EVjbrTdPz5NCHWuFVj"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DmLgB9Yri7NIMkocfX68EugbQaY>
Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 13:26:03 -0000

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 <stephen.farrell@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 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.farrell@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
>>>> 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
>>>>
>>>
>>>
>>>
>>
> 
> 
>