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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Jul 2018 12:40:54 -0400

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:  <[email-masked]>
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell <[email-masked]>, Kathleen Moriarty
<[email-masked]>

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Jul 2018 09:54:43 -0700

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 <
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Jul 2018 09:57:29 -0700

On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla <[email-masked]> wrote:

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

---

From: Andrei Popov <[email-masked]>
Date: Mon, 9 Jul 2018 18:00:16 +0000

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 <[email-masked]> On Behalf Of Eric Rescorla
Sent: Monday, July 9, 2018 9:57 AM
To: Kathleen Moriarty <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

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

Thanks in advance,
Kathleen

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

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&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518&sdata=%2BBRGmMbf7r4mXoyWqHmT6kgNjHw7Drh7ldDceG5gqfQ%3D&reserved=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&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518&sdata=Qge2nvcx8fz105Uux1rl1eM2yHiI7zbvxA8Pvps10z8%3D&reserved=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&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535&sdata=Bz6FrvviPoSIxkB83boGxcOxVg2NvrqS3A1bUinNodc%3D&reserved=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&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535&sdata=M1O48yPTPkd%2Bb3%2FE3z0%2FAniBUMozDwfQzp2Ra5sLRbQ%3D&reserved=0>

Abstract:

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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215031539&sdata=ixEPAZe51d1FhvdB9sQ8mzRHY04Blyx%2BIYjlFC%2Fo0dw%3D&reserved=0>.

The IETF Secretariat

--

Best regards,
Kathleen

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215041552&sdata=GkIXrs3zVeUBaEU2EUL8%2FXJdDdkDUlQ70iKr0rDJQRU%3D&reserved=0>

---

From: Alessandro Ghedini <[email-masked]>
Date: Mon, 9 Jul 2018 19:14:38 +0100

> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Jul 2018 18:42:25 +0000

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" <[email-masked]> wrote:

    Hello,

    
    Thanks in advance,
    Kathleen

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

    

    Abstract:

    

    The IETF Secretariat

    -- 
    
    Best regards,
    Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Jul 2018 18:46:12 +0000

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.

---

From: Loganaden Velvindron <[email-masked]>
Date: Mon, 9 Jul 2018 22:50:06 +0400

On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla <[email-masked]> 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.
>

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
> <[email-masked]> wrote:
>>
>> Hello,
>>
>> https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
>>
>> Status:

---

From: Eric Mill <[email-masked]>
Date: Mon, 9 Jul 2018 17:07:53 -0400

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 <[email-masked]>
wrote:

> Firefox
> >> https://www.ietf.
> .org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
> >>
> >> Status:
> >>

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: [email-masked] (Martin Rex)
Date: Tue, 10 Jul 2018 00:20:07 +0200 (CEST)

Andrei Popov <Andrei.Popov=[email-masked]> 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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 08:56:14 +1000

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

---

From: nalini elkins <[email-masked]>
Date: Tue, 10 Jul 2018 09:20:47 +0530

>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=[email-masked]> 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 <[email-masked]> *On Behalf Of * Eric Rescorla
> *Sent:* Monday, July 9, 2018 9:57 AM
> *To:* Kathleen Moriarty <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-
> oldversions-diediedie-00.txt
>
>
>
>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsftcd%2Ftls-oldversions-diediedie&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215001514&sdata=6JSQZe93nWnAELvOgG3KyIcPopQleMDtNF6v8LWFXWU%3D&reserved=0>
>
> Thanks in advance,
> Kathleen
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-moriarty-tls-oldversions-diediedie-00.txt&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518&sdata=%2BBRGmMbf7r4mXoyWqHmT6kgNjHw7Drh7ldDceG5gqfQ%3D&reserved=0>
> Status:
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-moriarty-tls-oldversions-diediedie%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518&sdata=Qge2nvcx8fz105Uux1rl1eM2yHiI7zbvxA8Pvps10z8%3D&reserved=0>
> Htmlized:
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-moriarty-tls-oldversions-diediedie-00&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535&sdata=Bz6FrvviPoSIxkB83boGxcOxVg2NvrqS3A1bUinNodc%3D&reserved=0>
> Htmlized:
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-moriarty-tls-oldversions-diediedie&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535&sdata=M1O48yPTPkd%2Bb3%2FE3z0%2FAniBUMozDwfQzp2Ra5sLRbQ%3D&reserved=0>
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215031539&sdata=ixEPAZe51d1FhvdB9sQ8mzRHY04Blyx%2BIYjlFC%2Fo0dw%3D&reserved=0>
> .
>
> The IETF Secretariat
>
>
>
> --
>
> Best regards,
> Kathleen
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215041552&sdata=GkIXrs3zVeUBaEU2EUL8%2FXJdDdkDUlQ70iKr0rDJQRU%3D&reserved=0>
>
>
>
>
>

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Jul 2018 00:17:56 -0400

On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:

> agree isn't ideal for several reasons.

Is the objection primarily to AES-128-CBC or to RSA key exchange?
With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it
outperforms AES-256-CBC, and the various CBC issues are resolved
via EtM.

> The ECDHE suites with AES-GCM

More generally, as noted in RFC7435, you get more security by raising
the ceiling than by raising the floor.  Breaking the ability to
communicate with legacy systems may feel satisfying, but does not
generally improve the security of the up-to-date systems, barring
downgrade issues in the protocol.

Therefore, we should focus on remediating any downgrade exposures,
those are serious issues regardless of the mix of supported algorithms,
and with downgrade under control, and up-to-date systems preferring
stronger algorithms, removal of obsolete algorithms becomes
considerably less urgent.  They can fade out of use gradually with
minimal disruption.

Setting the bar too high creates barriers to adoption of security
mechanisms.   Detailed example below, TL;DR turning off trust in
SHA-1 certificates is not always a good idea.

For example, I recently learned that current GnuTLS
versions by default no longer validate certificates with SHA-1
issuer signatures, and that current versions of Exim linked with
these GnuTLS releases fail to validate some DANE-TA(2) chains issued
by private-CAs that still use SHA-1.  And yet:

   * CA/B forum public CAs in the various browser bundles no
     longer issue SHA-1 certificates.

	https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/

   * Furthermore, they now also employ high-entropy unpredictabl
     serial numbers:

        https://cabforum.org/2016/03/31/ballot-164/

Thus there is no practical exposure to SHA-1 via the public CA
ecosystem, and as the issue is comprehensively addressed on the
issuer side.

Non-public CAs, on the other hand, are typically already compromised
by the time they can be convinced to issue certificates to untrusted
strangers, even if the hash algorithm is impeccably strong.  If an
organization designates its own private CA (that still issues SHA-1
signed certificates) as the trust-anchor for its SMTP servers, it
is counter-productive for the verifier[*] to demand greater security
connections to that site than the site deems necessary.

Thus, ideally, either general purpose TLS libraries (such as GnuTLS)
should not yet disable verification of SHA-1 certs in their chain
verification code, or else, Exim and other applications need to
explicitly override the default settings and re-enable SHA-1.

Yes, in practice, given that getting the world to change their
deployed systems is hard, also the private CAs using SHA-1 will
need to switch to SHA-2 to regain interoperability, despite no
actual risk from SHA-1.

For the record, SHA-1 use is not common.  From the SMTP DANE adoption
survey, looking at the 537 distinct leaf certificates of the 655
MX hosts with DANE-TA(2) (issuer-CA rather than the much more popular
DANE-EE(3) leaf cert) TLSA records I observe the below signature
algorithm frequency:

 496     Signature Algorithm: sha256WithRSAEncryption
  27     Signature Algorithm: sha512WithRSAEncryption
   8     Signature Algorithm: sha1WithRSAEncryption
   4     Signature Algorithm: ecdsa-with-SHA256
   2     Signature Algorithm: sha384WithRSAEncryption

So Exim with recent GnuTLS fails to authenticate 8 MX hosts, serving
around 30 domains, due to deprecation of SHA-1 in a context where
it is largely unnecessary and is somewhat counter-productive.

-- 
	Viktor.

[*] The verifier is almost always employing opportunistic DANE TLS,
    and is even willing to send cleartext when DNSSEC-secure DANE
    TLSA records are absent and STARTTLS is absent or stripped.
    Thus the use of mandatory TLS is at the receiving domains's
    prerogative.  Holding the receiing system to a higher security
    bar than it provisioned is counter-productive.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Jul 2018 09:21:04 +0100

Hi Nalini,

> only statistics on browsers.   The real usage of these protocols is far

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

---

From: Hubert Kario <[email-masked]>
Date: Tue, 10 Jul 2018 15:38:42 +0200

> downgrade issues in the protocol.

The github version of the document points out that the security of TLS 1.2 
downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.

that is the downgrade issue in the protocol

https://github.com/sftcd/tls-oldversions-diediedie/blob/
bd6bdc37ec258094f1e1010fba19e8763f2beaee/draft-moriarty-tls-oldversions-
diediedie.txt#L142-L145
-- 
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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Jul 2018 07:03:24 -0700

> downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.

Well, yes and no. If you allow static RSA, then yes.  If you require
(EC)DHE, then the anti-downgrade measures in the TLS 1.3 random values are
intended to protect against downgrade even if SHA-1 is compromised (because
the randoms are signed).

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Jul 2018 14:07:06 +0000

nalini elkins <[email-masked]> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Jul 2018 07:08:25 -0700

Foillowing up: of course this doesn't protect you from 1.2 -> 1.0 downgrade
unless you backport the mechanism to your 1.2 implementation, which I
expect many people will not do, despite the specs.

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Jul 2018 14:16:57 +0000

Viktor Dukhovni <[email-masked]> writes:

>also the private CAs using SHA-1 will need to switch to SHA-2 to regain
>interoperability, despite no actual risk from SHA-1.

Another problem with moving to SHA-2 is that when you have a lot of gear that
only does SHA-1, you need to run parallel PKIs possibly in perpetuity, one
using SHA-1 and the other SHA-2.  For example if you're signing CRLs then you
have SHA-2-signed ones and SHA-1-signed ones, and then the CA/signing certs in
turn have to be signed with SHA-1 or SHA-2, and the CA certs for those have to
be SHA-1 or SHA-2, and you can see what a headache that ends up being, not
just in terms of running two PKIs but also the fact that you've now got lots
of apparently duplicated certs that differ only in their hash algorithm.  Or
you can use different keys, but now you also need to change the DNs otherwise
sigs on the SHA-1 branch won't verify on the SHA-2 branch.  No matter how you
look at it, you end up with a mess.

(Luckily this sort of thing is Someone Else's Problem, and I don't envy them
for it).

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 10 Jul 2018 17:32:29 +0200

> intended to protect against downgrade even if SHA-1 is compromised (because

but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1...

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Jul 2018 15:45:16 +0000

>but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1...

... but with EMS or LTS in effect, with a lot more than that.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Jul 2018 12:01:50 -0400

> downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.

Is this accurate?  TLS 1.0 uses a combined SHA-1 + MD5 PRF.  Are
there known attacks that compromise TLS 1.0 via collisions in its
PRF?

[ IIRC, one embarrassing feature of TLS 1.2 vs. TLS 1.0 is that in making
  the signature algorithms negotiable, it became possible to offer and
  use MD5 where previously TLS 1.0 used SHA-1. ]

> that is the downgrade issue in the protocol

Keep in mind that my example, illustrating potentially counter-productive
raising of the floor, was about SHA-1 signatures in certificates.
Does accepting SHA-1 signatures in *certificate chains* create
opportunities to downgrade TLS 1.2 to TLS 1.0?

For the record, I am not saying that users should not be moving to
TLS 1.2 (if they haven't already).  Rather, I'm not aware of practical
cryptographic downgrade attacks to TLS 1.0 (other than software
that might still pessimistically fall back to TLS 1.0 on TLS 1.2
handshake failure).

Absent, such downgrade attacks, what's really needed is broader
support for TLS 1.2 (raising the ceiling), which does not require
removal of support for TLS 1.0 (raising the floor).

As a community we're still prone to pursue improved security primarily
through removal of weak algorithms, and under-appreciate security
improvement via the introduction of stronger algorithms.

Of course removal of weak algorithms has its place, if these
facilitate downgrade attacks, or present unnecessary attack-surface
once no longer used.  But we should be careful to not rush into
overzealous deprecation that can sometimes do more harm than good.

-- 
	Viktor.

---

From: David Benjamin <[email-masked]>
Date: Tue, 10 Jul 2018 12:10:08 -0400

On Tue, Jul 10, 2018 at 11:46 AM Peter Gutmann <[email-masked]>
wrote:

> .... but with EMS or LTS in effect, with a lot more than that.
>

EMS does not fix the ServerKeyExchange signature payload. It's still just
the randoms and not the full transcript.

But, fixed or not, it is still signed with SHA-1. Ironically, while signing
the full transcript is indeed preferable, the SLOTH paper (see sections
V.A. and V.B.) shows how it actually then becomes *easier* to exploit a
weak hash function:
https://www.mitls.org/pages/attacks/SLOTH

David

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Jul 2018 16:38:22 +0000

David Benjamin <[email-masked]> writes:

>EMS does not fix the ServerKeyExchange signature payload. It's still just the
>randoms and not the full transcript.

Maybe we're talking about different things here, EMS hashes the full
transcript, for 1.0 and 1.1 with the dual SHA-1 and MD5 hash, for 1.2 with
whatever's negotiated, hopefully SHA-2 (even if SHA-1 is used, you've now got
two hashes you need to defeat simultaneously, not one).  So while the
ServerKeyExchange signature may not detect an attacker able to compromise
SHA-1 in real time (and that statement alone should tell you how feasible the
attack actually is), the later EMS will.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Jul 2018 14:04:38 -0400

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

---

From: Hubert Kario <[email-masked]>
Date: Tue, 10 Jul 2018 20:11:14 +0200

On Tuesday, 10 July 2018 18:38:22 CEST Peter Gutmann wrote:
> whatever's negotiated, hopefully SHA-2 (even if SHA-1 is used, you've now
> got two hashes you need to defeat simultaneously, not one).

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)

read the SLOTH paper for details and references

> So while the
> SHA-1 in real time (and that statement alone should tell you how feasible
> the attack actually is)

yes, _now_
not for "foreseeable future" and not after quantum computers come into play
-- 
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

---

From: Phil Pennock <[email-masked]>
Date: Tue, 10 Jul 2018 14:13:37 -0400

On 2018-07-10 at 00:17 -0400, Viktor Dukhovni wrote:
> the ceiling than by raising the floor.

+1, including to the points about SMTP fallback to cleartext, etc.

> by private-CAs that still use SHA-1.  And yet:

That's fine by me.  Linking against GnuTLS has long had implications for
mail delivery.  It blocked SSLv3 at a time when SSLv3 was still fairly
widespread in corporate circles (Exchange).  Folks who care about TLS
interop for real mail-systems use OpenSSL.

For myself, I think that since SHA-1 has practical collision attacks
today, the next break will be second preimage attacks, at which point
the use in certificates is dead.  Whether that comes tomorrow or three
years from now, I don't know.

It's appropriate to not re-enable SHA-1 at a point where the entire
non-SMTP ecosystem has moved away from it and nobody should be asking
_other people outside their own administrative domain_ to trust SHA-1 in
certs.  If folks want to use it internally, that's fine.  If you want to
use DANE-TA to expose your internal CA to the outside world, that's fine
too, but you need to meet the common minimum bar for protecting chain
integrity.

> ecosystem, and as the issue is comprehensively addressed on the

Today, no.  But when SHA-1 is already so broken that 2nd preimage is the
only remaining step to fall before it becomes unsuitable for certs, it's
certainly not good to encourage its continuing usage.

> strangers, even if the hash algorithm is impeccably strong.

And this step then falls because if considering the next break rather
than "publicly known today" then the "issuing to untrusted strangers"
stops being a prerequisite for attack.

> For the record, SHA-1 use is not common.

Not common enough for me to do more than update the Exim Specification
to include a warning, which I'll do shortly.

On 2018-07-10 at 00:43 -0400, Viktor Dukhovni wrote:
> All the below have DANE-TA(2) TLSA RRs, with SHA-1 leaf sigs.
> 
>     semidefinite.de
>     iki.fi
[ *.iki.fi ]

So looks like two organizations total.  I'm not encouraging a time-bomb
break in TLS security for two orgs.

Thanks for bringing this to my attention.  I'll update docs shortly.

-Phil

---

From: Hubert Kario <[email-masked]>
Date: Tue, 10 Jul 2018 20:39:28 +0200

> there known attacks that compromise TLS 1.0 via collisions in its

that's what SLOTH was about (among other things)

> opportunities to downgrade TLS 1.2 to TLS 1.0?

ah, then I misunderstood, sorry

for certificates, the answer is "not immediately", and "harder"

as that requires either the ability by attacker to get a cert from an internal 
CA (that it can the calculate collision for) or a preimage attack on SHA-1 
signatures (which is significantly harder than chosen prefix)

> removal of support for TLS 1.0 (raising the floor).

do we have access to other incentives than breaking compatibility with old 
stuff?

> improvement via the introduction of stronger algorithms.

aren't new strong algorithms only effective when they are actually used 
though?

> overzealous deprecation that can sometimes do more harm than good.

my opinion is that published RFCs should represent _current_ best practice, if 
only because we will have to live with stuff that is deployed new for 10 years 
if not more
-- 
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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Jul 2018 21:25:29 +0100

Hiya,

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

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.

> higher incidence of TLS 1.0-only servers.

Fair point.

Cheers,
S.

---

From: [email-masked] (Martin Rex)
Date: Tue, 10 Jul 2018 22:31:32 +0200 (CEST)

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

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

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 Jul 2018 04:57:59 +0000

>not much harder than breaking just one of them (increase of work factor less

"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.  In fact the sole (significant) surviving member of the MD5/SHA-1 era,
RIPEMD-160, remains unbroken and uses dual hash chains within the same
function, not even as two independent functions.

So I'm not losing any sleep over this.

>not after quantum computers 

 ... or captured alien technology, or magic, or anything involving pyramids or the
  Aztecs...

>come into play

Yeah, not losing any sleep over those either.

Peter.

---

From: nalini elkins <[email-masked]>
Date: Wed, 11 Jul 2018 11:15:28 +0530

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 <[email-masked]>
wrote:

> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast
> er/draft-moriarty-tls-oldversions-diediedie.txt
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jul 2018 10:50:45 +0100

Hiya,

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

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

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

> disregard SSH and other such variants.)

Again, that's not so interesting here.

> 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

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.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 11 Jul 2018 13:06:21 +0200

On Wednesday, 11 July 2018 06:57:59 CEST Peter Gutmann wrote:
> >not much harder than breaking just one of them (increase of work factor
> >less than 2)
> 
> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jul 2018 06:06:04 -0700

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Jul 2018 15:15:34 +0000

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Jul 2018 12:39:16 -0400

Sent from my mobile device

> On Jul 10, 2018, at 4:31 PM, Martin Rex <[email-masked]> wrote:
> 
Martin,

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

Thank you,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Jul 2018 12:44:35 -0400

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 

> On Jul 11, 2018, at 5:50 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Jul 2018 12:47:28 -0400

Contributions with data are welcomed and encouraged.

Thank you,
Kathleen 

> On Jul 10, 2018, at 10:07 AM, Peter Gutmann <[email-masked]> wrote:
>

---

From: David Benjamin <[email-masked]>
Date: Wed, 11 Jul 2018 13:37:46 -0400

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

>>> <https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt>
>>> Status:
>>>

---

From: nalini elkins <[email-masked]>
Date: Fri, 13 Jul 2018 08:24:48 -0400

Stephen,

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

>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

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Jul 2018 05:35:39 -0700

On Fri, Jul 13, 2018 at 5:24 AM, nalini elkins <[email-masked]>
wrote:

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

> On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hiya,
>>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2018 14:25:49 +0100

Hiya,

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

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

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

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

> has n% of TLS1.0 clients provides a potential attacker too much

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

---

From: Christopher Wood <[email-masked]>
Date: Fri, 13 Jul 2018 19:04:43 -0700

(Chair hat off.)

On Wed, Jul 11, 2018 at 10:37 AM, David Benjamin <[email-masked]> wrote:
> 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

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 14 Jul 2018 19:59:01 +0300

> out then. But I do understand organisations being shy about

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

---

From: Hubert Kario <[email-masked]>
Date: Mon, 16 Jul 2018 13:11:22 +0200

> be ashamed :-) and certainly not information that you'd want to share

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

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 20 Jul 2018 15:54:47 +0100

On 07/09/2018 05:40 PM, Kathleen Moriarty wrote:
> 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