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

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 12:10:42 -0400

I was going to hold off on suggesting this due to other topics dominating the list, but we might be in a kill-the-old-junk mood due to the latest old-junk vulnerability, so...

Old versions of TLS need to be phased out at some point (even the one we're designing now), however the current modus operandi is generally to wait until a catastrophic breakage forces everyone into a panic disable. I'd like to at least try to do better prior to the next time. I'd like to propose giving servers & clients different expectations as a transitional measure:

1) No general change to current TLS other than pointing to the UTA BCP from time to time.
https://tools.ietf.org/html/rfc7525

2) For TLS 1.3, add a blurb to the effect of:
"Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason.
Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."

The reasoning here is that major server updates are unfortunately uncommon, but client updates are routine. Server implementations get updated, but deployments don't/can't keep up. There are no legitimate clients that do not support TLS 1.2, and even plenty of old ones can support it if actually enabled (and those vendors should get their act together and push updates to flip that on for all old versions, regardless of EOL status). The current strategy is basically to support everything forever and that has been shown to be quite detrimental, especially over the past year.

Note that this is not just about dropping support for versions X & Y. It's about giving implementations a chance to drop all the baggage that comes with those old versions and focus only on reasonably modern standards instead.

For those that would disagree with mandating servers drop support for the protocol from 1999, I think it's reasonable to just require you to have to ignore the RFCs if you really want to keep doing this sort of thing in 2015. Everyone else should have servers that have at least vaguely reasonable minimum standards out-of-the-box. Allowing obsolete security to be considered legitimate is a public hazard, and I don't want to wait around for more exploits to deal with it. Security is only as strong as the weakest link; we need to start baking this into new specifications

Dave

PS
I am aware some vendors irresponsibly abandoned lots of mobile users on obsolete OS versions. They should be treated like WinXP+IE6: useless until you download a better browser yourself. If that's not possible, complain to the hardware vendor that didn't provide updates.

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 21 May 2015 16:45:25 +0000

> Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."

In Implementations like OpenBSD, this is already happening. For
example. libtls supports 1.2 by default.

> I am aware some vendors irresponsibly abandoned lots of mobile users on obsolete OS versions. They should be treated like WinXP+IE6: useless until you download a better browser yourself. If that's…

With Android One label, Things are slightly less worse now.

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 May 2015 20:47:30 +0300

> On May 21, 2015, at 7:10 PM, Dave Garrett <[email-masked]> wrote:
> 

Is this needed for interoperability, or is this just a good idea that you want to slap a MUST on?

It’s the latter. It belongs in a BCP, not in the protocol document, and that is where it already is. It’s not the IETF’s job to make deployment decisions like that.

Yoav

---

From: Thijs van Dijk <[email-masked]>
Date: Thu, 21 May 2015 21:07:23 +0200

On 21 May 2015 at 18:10, Dave Garrett wrote:

> Old versions of TLS need to be phased out at some point (even the one
> we're designing now), however the current modus operandi is generally to
> wait until a catastrophic breakage forces everyone into a panic disable.
> I'd like to at least try to do better prior to the next time. I'd like to
> propose giving servers & clients different expectations as a transitional
> measure:
>

In an ideal world I'd be all for it, but in reality I think this would do
more harm than good in the sense that it would postpone deployment of
TLS1.3 rather than speed up the deprecation of 1.1 and 1.0.

Case in point: as of last month, 15-20% of my employer's revenue still
comes from clients using IE6-8. (Mostly law firms and government branches
who don't care so much about security as they do about liability - if at
all. And barring the n'th catastrophic breakage, TLS1.1 is not a
liability yet.)
My boss isn't going to forfeit that amount of cash simply because his IT
guy says the BCP says he should. Nor should he! If it's an exclusive choice
between either supporting 1.0 and 1.1 but not the newest 1.3, OR having 1.3
but having to make do without one-sixth of his revenue, this is a
no-brainer.

Users and site operators alike would benefit the most from a
having-your-cake-and-eating-it-too scenario, where users with a modern
browser can enjoy the newest security features, while the soft-touch
deployment will make adopting the newer version more palatable for the
managers of this world, even if it does mean the odd panicky removal every
other month.

-Thijs

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 21 May 2015 15:22:56 -0400

> Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."
Now might be a good time to add a (3) for TLS 1.3: have a client
specify both the least TLS version they are willing to use, and the
greatest TLS they desire to use. And MAC or derive from it it so it
can't be tampered or downgraded.

You can still provide the the TLS record layer version, and you can
keep it un-MAC'd so it can be tampered with to cause a disclosure or
crash :)

Effectively, that's how the versions in the record layer and client
protocol are being used. It stops those silly dances the browsers and
other user agents perform without the need for TLS Fallback SCSV.

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 15:55:11 -0400

On Thursday, May 21, 2015 03:22:56 pm Jeffrey Walton wrote:
> greatest TLS they desire to use.

The new version negotiation proposal I was working on has that capability.
https://github.com/tlswg/tls13-spec/compare/master...davegarrett:EVN

The similar system I proposed before that was exactly (3), but this one just does a simple list. I greatly prefer the list based approach because it's a total replacement and mistake resistant. (this was discussed quite a bit a while ago on list) If people keep screwing up the old system, tweaking it a bit doesn't seem like enough to deal with the problem, and this new route has other benefits. (there's no reason why TLS 1.2 servers couldn't use it too, if desired)

Ditching TLS 1.0/1.1 support from the list-based approach would be fine and simplify things slightly (I could drop one paragraph), but it doesn't address the fact that servers will still have the code loitering around for a downgrade attack of some unknown kind. The fact that technically clients didn't support EXPORT ciphers did not stop the FREAK attack. TLS implementations have a fairly sloppy track record in this area, as of late.

I don't want negotiations to avoid old junk, or signaling suites to check for junk, or config options, or build options. The obsolete code needs to be stripped from the codebase. Nuke it from orbit. It's the only way to be sure.

Dave

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 21 May 2015 23:03:17 +0200

On Thu, May 21, 2015 at 12:10:42PM -0400, Dave Garrett wrote:
> 
> The reasoning here is that major server updates are unfortunately uncommon, but client updates are routine.

So everybody can already disable TLS 1.0 and 1.1 now, right?  All
clients have already been updated.

Kurt

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 17:12:54 -0400

> clients have already been updated.

More than enough, as far as I'm concerned. Once servers start rejecting the stragglers on EOL clients, people will be forced to update. This coercion does not work well in the other direction. Many server operators don't even care, or possibly even know anything about the topic. They do know that major upgrades of servers are a big deal, and something that does not get done frequently. Client upgrades, on the other hand, are easier to install and it's easier to switch to competitors if needed.

Dave

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 21 May 2015 14:30:52 -0700

> we're designing now), however the current modus operandi is generally 
> to wait until a catastrophic breakage forces everyone into a panic 
> disable. I'd like to at least try to do better prior to the next time. 
> I'd like to propose giving servers & clients different expectations as 
> a transitional measure: 
> 
> "Server TLS implementations supporting TLS 1.3 or later MUST NOT 
> negotiate TLS 1.0 or TLS 1.1 for any reason. 
> In an ideal world I'd be all for it, but in reality I think this would 
> do more harm than good in the sense that it would postpone deployment 
> of TLS1.3 rather than speed up the deprecation of 1.1 and 1.0. 
> 
> comes from clients using IE6-8. (Mostly law firms and government 
> branches who don't care so much about security as they do about 
> liability - if at all. And barring the n'th catastrophic breakage, 
> TLS1.1 is not a liability yet.) 
> My boss isn't going to forfeit that amount of cash simply because his 
> IT guy says the BCP says he should. Nor should he! If it's an exclusive 
> choice between either supporting 1.0 and 1.1 but not the newest 1.3, OR 
> having 1.3 but having to make do without one-sixth of his revenue, this 
> is a no-brainer. 
> 
> managers of this world, even if it does mean the odd panicky removal 
> every other month. 
> 
> -Thijs 

Andrei Popov: I think it would be trivial to release an update for IE8-10 for Win7 to enable TLS 1.1 and 1.2 by default, right?

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 May 2015 00:50:26 +0300

> On May 22, 2015, at 12:30 AM, Yuhong Bao <[email-masked]> wrote:
>> 

<snip />

> Andrei Popov: I think it would be trivial to release an update for IE8-10 for Win7 to enable TLS 1.1 and 1.2 by default, right? 

Trivial or not, whether Microsoft does this is not our decision. Probably not even Andrei’s decision. And these are not the 90s. People keep using computers for 5, even seven years. 

According to netmarketshare.com Windows XP is still 16% of desktops/laptops (as measured by web traffic). Add some older mac OS X versions and you reach 17%. Even mobile has some older versions. What this is proposing is to require servers to cut all of those off as a pre-requisite to supporting TLS 1.3.

Yoav

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 18:16:41 -0400

> According to netmarketshare.com Windows XP is still 16% of desktops/laptops (as measured by web traffic). Add some older mac OS X versions and you reach 17%. Even mobile has some older versions. Wh…

Windows XP & old Mac OS X users can install Mozilla Firefox or Google Chrome (or one of the browsers based on one). It's just the built in browser that won't work because the vendor dropped support.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 May 2015 01:34:08 +0300

> On May 22, 2015, at 1:16 AM, Dave Garrett <[email-masked]> wrote:
> 

And you are proposing that we force them to do this? Worse, you are proposing that we deputize all server operators in forcing them to replace their browser?

---

From: Watson Ladd <[email-masked]>
Date: Thu, 21 May 2015 18:41:48 -0400

> And you are proposing that we force them to do this? Worse, you are proposing that we deputize all server operators in forcing them to replace their browser?

If not now, then when?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 May 2015 01:59:17 +0300

> On May 22, 2015, at 1:41 AM, Watson Ladd <[email-masked]> wrote:
> 

When those machines rust away, or when their owners decide to buy shiny new ones.

Ultimately, it’s up to the server administrators to decide when to drop support for something. I don’t see where it’s our job to require them to do so as a pre-condition to deploying TLS 1.3. Server implementers will ignore this even if we make it a MUST.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 19:03:03 -0400

> And you are proposing that we force them to do this? Worse, you are proposing that we deputize all server operators in forcing them to replace their browser?

Force them to not use IE8? Oh, the humanity.

I'm saying it's a joke to say a server is secure when it still knowingly supports a security protocol from 16 years ago that has been replaced 3 times over. (2, prior to 1.3) At minimum, I'm saying a server that actually does that shouldn't be allowed to pretend it's compliant with modern security standards.

Every time there's some new catastrophic vulnerability that's discovered (but of course, always existed) that involves some decade plus old junk, people feign surprise and slowly get around to dealing with the issue. This latest weak DH issue has been known to exist in some form for years, yet now, all of a sudden, we're bothering to deal with it because someone found out it was worse. There are trivial measures that, whilst having massive consequences, can be done proactively with real effect. Agreeing to disable protocols leftover from the '90s is a start. We know TLS 1.0 and 1.1 are not as secure as they should be, that's why TLS 1.2 exists and why TLS 1.3 is being designed. It's not some secret; they were replaced for legitimate reasons that we should stop ignoring if we want this protocol to have legitimacy.

I'd like to be able to point to the TLS 1.3 spec and tell people that servers implementing it are as secure as we currently know how to make them, which is just not true unless their weakest link isn't obsolete crap.

Dave

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 May 2015 02:09:42 +0300

> On May 22, 2015, at 2:03 AM, Dave Garrett <[email-masked]> wrote:
> 

Then point at the BCP. Only problem is that it doesn’t say what you want it to say (it allows TLS 1.0 when the client does not support anything else)

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 19:20:21 -0400

On Thursday, May 21, 2015 06:59:17 pm Yoav Nir wrote:
> Server implementers will ignore this even if we make it a MUST.

So be it. As said before, there are no IETF police. Responsible server implementations will follow the spec and the ones who want to trade security for compatibility will not. Certainly not ideal, but it'd be a big improvement over everyone ignoring things until they explode. At bare minimum, when the inevitable new vuln is published, the organizations running compliant implementations will be able to show they took things seriously and everyone else did not. I'd at least like to write down the fact that everyone should be aware that it should be obvious that continuing to use an obsolete security protocol for over a decade and a half is not wise. It would help upgrade security more than ignoring the issue.

> Then point at the BCP. Only problem is that it doesn’t say what you want it to say (it allows TLS 1.0 when the client does not support anything else)

In my first post I said that I don't propose changing anything for existing deployments. The BCP is currently a "SHOULD NOT" for current TLS. I'm proposing a "MUST NOT" for TLS 1.3+ implementations only.

The BCP is also not directly part of the TLS spec. What I'm suggesting is considering 1.0/1.1 to be not legitimate forever, not just not "best".

Dave

---

From: [email-masked] (Martin Rex)
Date: Fri, 22 May 2015 01:28:36 +0200 (CEST)

Dave Garrett wrote:
> "Server TLS implementations supporting TLS 1.3 or later
> MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason.

You have just been passionately fighting _for_ ignoring a requirement
in TLSv1.0->v1.2 that is extremely reasonable an interop-enhancing
requirement.

Now you're asking for addition of an obviously stupid requirement that
will obviously impair interop.

Such obviously bogus requirements are going to be entirely ignored
by a number of implementors, and they will get away with it with ease
just as the offenders of current requirements keep offending.

The bottom line result will be that you're in conflict with rfc2119
and driving the quality of the document into the ground, because it
will become more and more difficult to recognize which of the requirements
are really important for interoperability, and which are just political junk.

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2015 16:29:15 -0700

> Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."

I don't think that this is the right way to do this.

I'm happy to be the one wielding the stick when the time is right, but
I probably won't come here to do it.

Implementations and operators of those implementations will make that
determination on their own, based on their own needs.  For example, we
support crappy crypto on the Firefox download site - including SSL3 -
on the basis that it makes more sense to allow clients who only
support SSL3 to download our software.  That way, they might get an
approximation of good crypto rather than being left with the rubbish
they have.

We have a very different policy for our accounts servers, of course.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 19:54:23 -0400

I'll make my reply to your previous email brief and simple. Replying with quoting would not be productive.

My stance is not particularly complex. I want the best interop that's possible without compromising security in any meaningful way.

Continued acceptance of 16 year old security protocol:  Bad
Different ordering of certificates on the wire:  I don't care
Ignoring the predictability of future vulnerabilities in known-obsolete stuff:  Bad
Writing down what's needed to actually be secure in the new security spec:  Good

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 21:53:14 -0400

> I don't think that this is the right way to do this.

I think it's probably the only way to set up a deprecation plan rather than rely on panic disables. I do agree that it's not looking viable.

> I probably won't come here to do it.

This standardization process is ill-equipped to deal with the issue, but it's the best place to try, near as I can tell. :/

> we support crappy crypto on the Firefox download site - including SSL3 -

Yeah, browser download servers are the notable edge case. Pretty much everyone would agree that anything is better than nothing there. Ideally SSL3 could be dealt with via a separate server, but I certainly agree with their assessment that the complexity of actually doing that isn't worth it.

Dave

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 22 May 2015 04:52:16 +0200

Hi,

> I don't think that this is the right way to do this.

I agree. While this is a noble effort, it's the wrong approach to
the problem at hand in my opinion. We do have a BCP from UTA which a
lot of work was put into. It basically tells people to deprecate
everything that's not TLS 1.2 with an AEAD.

> I probably won't come here to do it.

So how about that TLSv1-diediedie document? :)

Aaron

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 21 May 2015 19:56:22 -0700

> So how about that TLSv1-diediedie document? :)

I am very much +1 for more diediedie documents ;)

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 23:04:11 -0400

> I am very much +1 for more diediedie documents ;)

I'm certainly not going to argue against that. ;)

That said, the RC4 diediedie is getting largely ignored. To actually kill something like this off, it seems to need to be done as a panic response or as a requirement of something new that everyone starts together. (e.g. SSL3 diediedie or old TLS with HTTP/2) Thus was my reasoning for at least attempting to suggest it here. :|

Dave

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2015 20:06:36 -0700

On 21 May 2015 at 20:04, Dave Garrett <[email-masked]> wrote:
> That said, the RC4 diediedie is getting largely ignored.

That's not true.  I think that you expect something as large as the
Internet to move on timescales that just aren't feasible.  There's an
entire supply chain that has to move here.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 23:14:57 -0400

> entire supply chain that has to move here.

Fair enough; ignored is not the right word.

I should say instead that I have not seen a change nearly on the scale of the SSL3 RFC. Those who were in the process of phasing out RC4 are still doing so at a comparable pace. Browsers were willing to accept breakage for SSL3, but they're not yet ready for RC4. In comparison it appears to have had less effect, at least so far. This will, of course, hopefully change.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 22 May 2015 05:20:30 +0200

> That said, the RC4 diediedie is getting largely ignored. To actually kill something like this off, it seems to need to be done as a panic response or as a requirement of something new that everyone…

I don't have that impression at all. The RC4 and SSLv3 deprecation
documents even got (some) media attention, which is quite rare for
IETF documents. Same with the UTA BCP on TLS and attacks.

As suggested in the starting post this would effectively mean that
an implementation that does support 1.3 MUST NOT support anything
lower than that. Which -- of course -- means you're locking users
out that only have poor/bad crypto at hand. Somewhat refering to the
opportunistic debate; it's again bad crypto vs. no crypto at all. :/

Aaron

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2015 20:42:15 -0700

> I should say instead that I have not seen a change nearly on the scale of the SSL3 RFC. Those who were in the process of phasing out RC4 are still doing so at a comparable pace. Browsers were willi…

There is a big difference in the baseline in both cases.  RC4 was
about half of all TLS on the web before we decided to start killing
it.  You can't shift something like that quickly.

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 21 May 2015 20:49:15 -0700

On Thu, May 21, 2015 at 8:04 PM, Dave Garrett <[email-masked]>
wrote:

> That said, the RC4 diediedie is getting largely ignored. To actually kill
> something like this off, it seems to need to be done as a panic response or
> as a requirement of something new that everyone starts together. (e.g. SSL3
> diediedie or old TLS with HTTP/2) Thus was my reasoning for at least
> attempting to suggest it here. :|
>

I managed to get RC4 shut off at Square. The only real point of contention
was Windows XP, which doesn't run a version of IE we support, so in the end
it wasn't that much of an issue.

SSL Labs overall statistics paint a pretty dismal picture for the Internet
as a whole, but I think a lot of high profile sites have A or A+ ratings
(i.e. they've disabled RC4) these days which is nice

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Fri, 22 May 2015 00:59:57 -0400

> it.  You can't shift something like that quickly.

I'm not disputing that change is hard and slow. I'm saying it's a lot more effective if heavily coordinated, which in this case means high-profile panic or baseline expectations of a new standard. I like the latter a lot more. ;)

---

From: Xiaoyin Liu <[email-masked]>
Date: Fri, 22 May 2015 01:25:41 -0400

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

---

From: Dave Garrett <[email-masked]>
Date: Fri, 22 May 2015 02:26:04 -0400

On Friday, May 22, 2015 01:25:41 am Xiaoyin Liu wrote:
> 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.
[snip]
> 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.

I'd knock a year off that if possible, but yes, this is the other route that I would support... if it could actually be agreed to and enforced with a hardcoded time-check, not a human-flipped switch on the date. (humans are weak and squishy and liable to hesitate)

(out of order quoting)
> 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.

I know the push back against dropping TLS 1.0 via the TLS 1.3 spec is strong, but just dropping non-FS might actually be relatively easy (in comparison). FS is available in TLS 1.0 and is relatively commonly supported overall (~65% of TLS servers & increasing at 1-2%/mo [0]). By the time TLS 1.3 is ready for final release, making FS totally mandatory might actually affect relatively few users. Giving servers a few months lead to reject before clients stopping to offer might make things go more smoothly.

Dave

[0] https://www.trustworthyinternet.org/ssl-pulse/

---

From: [email-masked] (Martin Rex)
Date: Fri, 22 May 2015 09:42:40 +0200 (CEST)

Dave Garrett wrote:
>> Then point at the BCP. Only problem is that it doesn?t say what you want
>> it to say (it allows TLS 1.0 when the client does not support anything else)
> 
> In my first post I said that I don't propose changing anything for existing
> deployments. The BCP is currently a "SHOULD NOT" for current TLS.
> I'm proposing a "MUST NOT" for TLS 1.3+ implementations only.
> 
> The BCP is also not directly part of the TLS spec. What I'm suggesting is
> considering 1.0/1.1 to be not legitimate forever, not just not "best".

All current "recommendations" against TLSv1.0 and TLSv1.1 are well-known FUD.

The difference between TLSv1.0 with 1/(n-1) record splitting and
TLSv1.1 is cryptographically insignificant and the security of
TLSv1.2 is lower than both of its precedessors (e.g. throug the
botched TLS signature extension and the dumb idea to replace
the md5+sha1 signatures with sha1-only signatures for RSA certificates.

For the mandatory to implement TLSv1.2 cipher suite, TLSv1.0 and TLSv1.1
are just fine.  AEAD cipher suites are not part of TLSv1.2, they're
a mere optional add-on that is artificially limited to TLSv1.2, and a
number of TLSv1.2 implementations do not support AEAD cipher suites.

Same for Elliptic Curve.  It's optional, and to date, it is not even
standards track.  Many TLS implementations do implement EC.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Fri, 22 May 2015 12:44:07 +0200

On Friday 22 May 2015 09:42:40 Martin Rex wrote:
> >> it to say (it allows TLS 1.0 when the client does not support anything
> >> else)> 

schannel, OpenSSL, NSS and GnuTLS will use at least sha256 if only given 
chance

yes, clients should not be advertising support for sha-1, but it's not an end 
of the world scenario just yet

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

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 22 May 2015 12:30:49 +0000

Xiaoyin Liu <[email-masked]> writes:

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

This comment again shows the rather myopic browser-centered view of TLS that
I've complained about in the past.  For most of the users of TLS that I work
with, there is no browser, no OS upgrade, and no web.  TLS is used for
machine-to-machine communications, with no human intervention.  You know the
PLC I used as an example in an earlier message, the one that rejects any
attempt at connecting with a version number set to greater than TLS 1.0?  The
"upgrade" procedure for that is to replace it when the hardware dies, with a
minimum (minimum, not maximum) lifetime of around ten years (I've seen
refridgerator-sized PLCs dating from the 1960s still in active use today, but
that's because they're practically indestructible compared to modern
versions).

So if some sort of BCP is published, it should explicitly target browsers and
web servers where this kind of upgrade/change is possible.  Telling people to
throw away their PLCs and replace them with new ones isn't going to fly.

Peter.

---

From: Xiaoyin Liu <[email-masked]>
Date: Fri, 22 May 2015 09:16:37 -0400

From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
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))
Date: Fri, 22 May 2015 12:30:49 +0000

>throw away their PLCs and replace them with new ones isn't going to fly.

 Agreed! Xiaoyin

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 May 2015 15:18:24 +0000

> It belongs in a BCP, not in the protocol document

Yeah, and not even there.

Unless you area really saying that if I have a server that does TLS 1.3, it cannot talk to any currently-deployed client?  Yuk.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 May 2015 15:38:14 +0000

> More than enough, as far as I'm concerned.

Really?  10% of the traffic we see doesn't have SNI.    Most of the net doesn't support IPv6.

	/r$

---

From: Ronald del Rosario <[email-masked]>
Date: Fri, 22 May 2015 16:02:46 +0000

+1 on diediedocuments

Maybe it needs a “dedicated website + cool logo” ala heartbleed, FREAK, etc. to get noticed :-)

Ron del Rosario | @guerilla7

From: Dave Garrett <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 21, 2015 at 8:04 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)

Dave

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

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 22 May 2015 12:36:33 -0400

On Friday, May 22, 2015 11:38:14 am Salz, Rich wrote:
> Most of the net doesn't support IPv6.

This is an ISP issue. Plenty of clients support it, but their network won't route it.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 22 May 2015 13:13:01 -0400

> throw away their PLCs and replace them with new ones isn't going to fly.

To be clear, in case it was lost the noise, I did not propose mandating this in the TLS 1.3 spec. If you're going to be sticking with TLS 1.0 until the wheels fall off, you'll be sticking with other TLS 1.0 software to connect to it. (which might entail forking software into TLS 1.0-1.2 & TLS 1.2-1.3 variations, if you really have to) The proposals for the TLS 1.3 spec are intended to apply only to things that are actually updating. The idea is to drag the whole ecosystem kicking and screaming into the 21st century. If the ecosystem isn't moving at all, there's nothing we can do about that here. :(

Dave

---

From: Geoffrey Keating <[email-masked]>
Date: 22 May 2015 10:22:06 -0700

Peter Gutmann <[email-masked]> writes:

> You know the PLC I used as an example in an earlier message, the one
> that rejects any attempt at connecting with a version number set to
> greater than TLS 1.0?  The "upgrade" procedure for that is to
> replace it when the hardware dies, with a minimum (minimum, not
> maximum) lifetime of around ten years (I've seen refridgerator-sized
> PLCs dating from the 1960s still in active use today, but that's
> because they're practically indestructible compared to modern
> versions).
> 
> So if some sort of BCP is published, it should explicitly target
> browsers and web servers where this kind of upgrade/change is
> possible.  Telling people to throw away their PLCs and replace them
> with new ones isn't going to fly.

Telling people that these PLCs are secure and everything is fine and
they don't need to worry won't fly either.  The owners of these
devices are going to have to find a solution, whether it's an early
hardware upgrade, firmware replacement, or a front-end
translator/firewall.

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 22 May 2015 10:23:58 -0700

>  Maybe it needs a “dedicated website + cool logo” ala heartbleed, FREAK,

diediedie.ietf.org? ;)

-- 
Tony Arcieri

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 22 May 2015 13:56:45 -0400

> that's because they're practically indestructible compared to modern

+1. That toxic browser thinking and its polluted security model is
making its way into non-browser areas, too.

For example, browsers apparently embrace user phishing, claiming
"there's nothing we can do when a user make a configuration change
like adding a CA to the trust store." Then, in a
life-is-stranger-than-fiction moment, we get a standard like Public
Key Pinning with Overrides, where adversaries are allowed to break
known good pinsets because a user was phished.

Jeff

---

From: Bill Frantz <[email-masked]>
Date: Fri, 22 May 2015 14:52:46 -0700

>This is an ISP issue. Plenty of clients support it, but their network won't route it.

Here is another case where revenue models have a significant 
impact on security. (Another is the CA system.) ISPs charge 
extra for IP addresses that can run servers. If every device has 
its own IPv6 address, then every device can run a server. ISPs 
like IPv4 and NAT.

If you want earlier versions of TLS to die, figure out a revenue 
model for someone which will cause them to help make that 
happen. (No, I can't think of one immediately either.)

In the case of Peter's "living forever" devices, there may be a 
revenue model in replacing them. But that kind of replacement 
sounds like 1950s US auto makers planned obsolescence.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 May 2015 11:27:46 +0000

Geoffrey Keating <[email-masked]> writes:

>Telling people that these PLCs are secure and everything is fine and they
>don't need to worry won't fly either.  The owners of these devices are going
>to have to find a solution, whether it's an early hardware upgrade, 

Will never happen.

>firmware replacement, 

Typically can't be done.

>or a front-end translator/firewall.

As above.

For people who have never worked with these kinds of devices before, here's an
overview:

-- Snip --

[...]

SCADA devices often resort to all manner of exotic designs in order to provide
this high level of availability.  One such technique involves the use of
differential switching on all circuits, in which a value of |||false||| is
represented by a 0 signal on one line and a 1 on the other and a value of
|||true||| with signal values of 1 and 0.  If both lines are unpowered (due to
a loss of power) or powered (due to a short circuit) or the signal is present
statically (due to latch-up in a circuit) rather than dynamically (driven by a
clock pulse) then it's regarded as an error condition.

The clock pulse isn't necessarily a standard CPU clock but merely a
capacitively-coupled AC signal (so that applying standard DC power to the
circuit won't produce an output signal) that acts as an additional gating
signal that has to be present in order for things to work.  Even basic passive
components like resistors are mounted in such a way that they can't easily be
bypassed by a short circuit, for example by having the circuit traces that the
two ends of the resistor are soldered to on opposite sides of a double-sided
circuit board.

That's just the lowest level of the system.  Once you get above the basic
switching circuits you get into redundant buses, self-checking logic,
heterogeneous designs (for example an AND gate can be implemented as both |||a
AND b||| and |||NOT a OR NOT b|||, with the two circuits checking each other),
majority-logic decoding, and in general entire books full of exotic design
principles that would never be used in a standard system.

[Further discussion]

The overall rationale for not thinking too much about security is that there's
a higher risk created when a critical device isn't working due to a particular
security measure than through having some possible, often rather theoretical,
security flaw present.

-- Snip --

So when given a choice of availability/reliability over security, availability
wins every time (and quite rightly so).  The only time you can fiddle with it
once it's in place, ever, is when there's a clear and present issue that
affects availability.  "Race condition when reading vibration sensors is
causing the rotor-imbalance safety cutout to trip and take turbine #3 offline"
is a clear and present issue.  "Haxors might 0wn us" is not, so it'll be
addressed in the 2018-2023 product cycle.

Peter.

---

From: Geoff Keating <[email-masked]>
Date: Sun, 24 May 2015 14:05:35 -0700

> On 24 May 2015, at 4:27 am, Peter Gutmann <[email-masked]> wrote:

> addressed in the 2018-2023 product cycle.

I guess there are two ways to interpret this.

One is that owners of some systems have carefully considered the relative danger of certain upgrades, decided that the necessary mitigation (testing, staged deployment, backup systems) for that danger is uneconomic, and have accepted the resulting risk.  Perhaps even computed the danger to the world as a whole and not just to them?

Another is that owners of some systems are reflexively against change without a clear and present danger and don’t care what the medium-term consequences might be.

I’m sure there are some of both, hopefully there are more of the first.

For both of these, it’s better to make a clear recommendation that early TLS versions are past their expiry date and are not to be used.  For the first kind of owner the costs of supporting the old versions will fall on them and not on the rest of the Internet, which will make their economic computation more accurate.  The second kind will discover that off-the-shelf products no longer talk to their ancient systems and will, slowly and painfully, eventually upgrade.

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 24 May 2015 19:24:14 -0400

On Fri, May 22, 2015 at 5:52 PM, Bill Frantz <[email-masked]> wrote:
> Here is another case where revenue models have a significant impact on
> security. (Another is the CA system.) ISPs charge extra for IP addresses
> that can run servers. If every device has its own IPv6 address, then every
> device can run a server. ISPs like IPv4 and NAT.

Some of the latest standards are removing IP addresses from X.509
certificates. It appears to be doing so without consideration for the
revenue model.

I think its more influence from the browsers because it shows up in
HTTP Strict Transport Security (HSTS), Appendix A; and the upcoming
Public Key Pinning with Overrides (HPKP).

Because its being influenced by the browsers, I'm guessing the only
revenue model being considered is the third party ad model, where a
client is told to fetch a resource and possibly execute code from a
third party server so the origin can get paid.

I don't know what the IETF's official policy is on DNS names versus IP
addresses.

Jeff

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 May 2015 13:10:23 +0200

> Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."

How is this different from TLS 1.1 and 1.2?  Both RFCs obsoleted its
successor, so from an IETF perspective, there is just a single version
right now, TLS 1.2, and everything else is non-conforming.

-- 
Florian Weimer / Red Hat Product Security