Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients))

From: Yuhong Bao <[email-masked]>
Date: Thu, 11 Jun 2015 16:26:15 -0700

I think disabling TLS 1.0 on servers is probably easier.
Remember that TLS 1.0 lasted for more than a decade. 
The reason disabling SSLv3 was trivial was that TLS 1.0 was already supported and enabled by default on most servers.
Even then there was the problem of extension intolerant and version intolerant servers that had to be upgraded.

Yuhong Bao
________________________________
> From: [email-masked] 
> To: [email-masked]; [email-masked] 
> Date: Fri, 22 May 2015 01:25:41 -0400 
> CC: [email-masked] 
> Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: 
> prohibit <1.2 support on 1.3+ servers (but allow clients)) 
> 
> Hi, 
> 
> Instead of prohibiting bad crypto on the server side, I would like to 
> propose a BCP which prohibits TLS 1.1- on the clients, but allows 
> servers to keep supporting TLS 1.0+. The simple reason is that we 
> should allow normal users to gradually upgrade their old 
> browsers/operating systems, but should encourage (or 
> require) webmasters to upgrade their servers as soon as possible in 
> order to protect their users' security and privacy. I believe phasing 
> out insecure web technology should be promoted by browsers. Microsoft's 
> plan to phase out SHA-1 certificates has been quite effective so far, 
> and I suggest we do the same for old TLS protocols and old cipher 
> suites. 
> 
> I do understand that, as many have pointed out, upgrading servers is 
> not an easy task for some companies. But if not now, they have to be 
> upgraded sometime. Is 2-3 years enough for all servers to be upgraded? 
> So what about specifying the following in tls1-diediedie doc: 
> 
> 1) (Already required in RFC 7525) TLS servers MUST support TLS 1.3 (if 
> TLS 1.3 RFC has been published, otherwise TLS 1.2). 
> 2) (Already required in RFC 7525) If ClientHello.client_version is 
> 0x0303 (TLS 1.2) or above, then TLS servers MUST negotiate that 
> version. 
> 3) TLS servers MAY support TLS 1.0 and TLS 1.1 to support old TLS clients. 
> 4) (New requirement!) Starting from January 1, 2018, TLS clients MUST 
> terminate the handshake if serverHello.server_version is 0x0302 (TLS 
> 1.1) or below. 
> 5) (New requirement!) Starting from January 1, 2018, TLS clients MUST 
> NOT include cipher suites that do not provide forward secrecy in the 
> ClientHello message. 
> 6) (Same as RFC 7525) The requirements above do not apply to 
> opportunistic encryptions, like STARTTLS. 
> 
> The date specified in 4) and 5) can be discussed later. It is 
> important that all major browser vendors agree to enforce 4) and 5) 
> after this specific date, and that this date is widely known by website 
> operators. The goal of my proposal is to eliminate TLS 1.0-only 
> and non-PFS TLS servers before the next decade. 
> 
> Best, 
> Xiaoyin 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jun 2015 10:17:21 -0700

> I think disabling TLS 1.0 on servers is probably easier.

That's not a terrible idea.  Clients won't follow when 9% of
connections still need 1.0 [1].

[1] http://telemetry.mozilla.org/#filter=release%2F38%2FSSL_HANDSHAKE_VERSION%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 12 Jun 2015 18:36:15 +0000

When I asked Bodo if you could make an attack for TLS 1.0, he said "oh, Labrador?"

He was joking.