HSTS was created specifically to prevent the MITM from downgrading HTTPS to HTTP.

As for MITM blocking a protocol, that is a noticeable situation, and one that does not give the attacker any control over the cryptography used on sensitive data. A downgrade attack is very different from blocking a protocol. The user doesn't notice, and the attacker gains some control over the cryptography used.

In the end, what sense does it make to have a TLS version an attacker can opt out of? All you get is defence against passive MitM. Until we aren't safe against those passive MitM with TLS 1.2 it makes no sense to rush TLS 1.3. Especially because that rush would really hurt when it turns our TLS 1.2 is insecure, at which point the rushed solution becomes vulnerable to all active MitM attacks.

Now consider, what level of access to infrastructure only allows for passive MitM?

> The user doesn't notice, and the attacker gains some control over the cryptography used.

In my case user will because the tls client wont accept insecure version request. Connection broken. Client will notify the user of server still using a insecure version.

I think this might be the misunderstanding: A good client/server never establish/accept insecure versions.

Yes MITM gets to pick but if he picks insecure version, there is no connection.

POODLE was never attack on the protocol but poor implementations.

One misunderstanding is that you are accepting as fact that TLS 1.2 is secure, when it's entirely plausible that one or more state actors already know that not to be the case.

There's no magic light that goes on when the NSA breaks TLS 1.2 so that we know to stop trusting it.

> Hows downgrading to _secure 1.2_ insecure ?

I could go back a few years and ask you the same question: "Hows downgrading to secure SSLv3 insecure ?" You could say "it wasn't", and then you could suddenly be facing a bunch of CVEs and a cute acronym. What makes 1.2 so special that truly, this time, there won't ever be any problems found with it? Especially when enough potential problems were found to motivate TLS 1.3?

> Regarding sslv3, why would client ever use it, downgrade/POODLE or not ?

At the time, downgrade attacks specifically forced SSLv3. So yes, why would a client ever enable downgrade attacks - intentionally, no less - is a very, very good question. Of course, we're only talking about downgrading to 1.2 these days - but we've already had the history to show us why downgrades are a bad idea, so why repeat that history?

> So what ? 1.2 is not weak. Connection is still secure.

For now. So was SSLv3, until it wasn't. At the bare minimum, it's a larger attack surface of extremely security sensitive code - which is worrying in it's own right - and an intentionally written security vulnerability which, while "not weak" today, may become weak or even exploitable in the future.

Completely future-proofing things is a losing game, of course, but seeing as insecure downgrade moots the point of 1.3 - strengthening security - it seems reasonable to try and figure out how to do things right "now" - or failing that, "before it becomes a crisis."

> Also MITM still gets to decide whether to have tls or not. Then "Why even have tls ?". If MITM is blocking a protocol (or higher version, which is equivalent), then there is nothing to be done.

Does your browser automatically downgrade HTTPS to HTTP if the former fails? I hope not! Connections failing when MITMed by unknown third parties is a feature when you're logging in to your bank. This single feature is basically the entire point of TLS, HTTPS, and the entire CA infrastructure. That's "why even have TLS". There is something to be done: Defer connecting to your bank until you're no longer on your current, terrible MITMing wifi connection. Maybe pick one of the other 20 hotspots on your connection list. As currently implemented, this requires some minor, manual intervention, on the part of the user.

TLS 1.3 with insecure downgrade accomplishes this no more effectively than 1.2. It's a waste of bits. It's why insecure downgrade to SSLv3 is gone - it was mooting the entire point of TLS.

> So yes, why would a client ever enable downgrade attacks - intentionally, no less - is a very, very good question.

No I meant a good client/server would never use sslv3.

> Completely future-proofing things is a losing game

I am not assumming any such thing. The moment 1.2 is known to be broken, every client/server should mark it insecure and never establish/accept 1.2 connection.

Assuming good client and good server are poodled, then no tls connection will be established.

> Defer connecting to your bank until you're no longer on your current, terrible MITMing wifi connection.

Which a good client already does without any anti-poodle fix.

I think this might be the misunderstanding: A good client/server never establish/accept insecure versions. If they get poddled, then no tls connection.

> No I meant a good client/server would never use sslv3.

They did. They don't now, but they did.

Eventually, a good client/server will never use TLS 1.2.

My point is that it's the same situation - just at different points in time, with different protocols.

> The moment 1.2 is known to be broken, every client/server should mark it insecure and never establish/accept 1.2 connection.

That's basically what happened with SSLv3. The moment SSLv3 was known to be broken, every client/server marked it insecure and never established/accepted a SSLv3 connection again. This took the form of hotfixes, CVEs, "crisis", etc. - after all, that's just when browser devs found out it was broken. Frequently, criminals and security agencies will find out before them.

To avoid repeating the exact same history of hotfixes, CVEs, and "crisis", you can patch out 1.2 proactively - before it's "known" to be vulnerable.

But either way - proactive or reactive - we end up in a future with TLS 1.3+ and no TLS 1.2 downgrade support eventually. Does releasing 1.3 early with downgrade support help accomplish that future? The TLS and browser devs seem to think that's a distraction, and that plain old TLS 1.2 will do just fine until they can make TLS 1.3 just work, without the downgrade support.

Sure, it delays the release of "TLS 1.3" a bit, but so what? It's not delaying the release of "secure against any future TLS 1.2 exploits" - the part that actually matters from a security standpoint.

And if I'm reading the "Making TLS 1.3 work" section of the article correctly, they're already nearly ready to roll out TLS 1.3 without downgrades: A 0.2% higher success rates with "Experimental changes" (TLS 1.3 without downgrade support?) than TLS 1.2 on Chrome somehow (possibly just within the sampling error rate) and a 0.05% drop in success rate in Firefox (again possibly within the sampling error rate.)

> I think this might be the misunderstanding: A good client/server never establish/accept insecure versions. If they get poddled, then no tls connection.

We agree there - but a better client/server drops support for "secure" versions before they become known to be "insecure".

Looks like we are making case for different things.

You are arguing that everyone should update to latest version asap. Because, as you say, older version is more vulnerable. I dont think thats true, case-in-point: macos root bug. What if criminals and security agencies has broken 1.3 but not 1.2 ? Dont fix it unless its broken. Fix it when its broken or predicted to be broken.

But thats different to what I was arguing for: Some poor 1.2 implmentations aborting connection when connecting to 1.3 client, is not a problem as the article says. For complete arguments, see my previous comments here.

> But either way ... the downgrade support.

What downgrade support ? Are you saying 1.3 browsers will only connect to 1.3 ? Because there is no way every/most 1.2 servers will just transition to 1.3 together. Before 1.3 becoming 99.9%, some will be using 1.3 and some 1.2. It just cannot be avoided.

The argument is not that we should update asap. The argument is that we should not reconnect using 1.2 when 1.3 fails. There is still the normal version negotiation mechanism in TLS that would allow clients that are willing to use 1.2 when the server does not support 1.3

The issue lies with servers that do not adhere to the standard regarding version negotiation. Your proposed solution (the 'insecure fallback') is about making a client deal with this in a way that is insecure when TLS 1.2 is insecure. Our proposed solution is to change version negotiation so the faulty servers continue to work.

As you noted, 1.2 is still secure. So at this moment, we don't need 1.3 (save for the advantages like 1RTT handshakes). Thus there is no security benefit to adapting 1.3 earlier.

Now, if 1.2 ever becomes insecure, insecure fallback means MitM can force 1.2 and then attack, even if both server and client are willing and capable of using 1.3. It is true that when 1.2 is insecure, neither clients nor servers should be willing to use it. However, slow updating or 'compatibility' might see servers and clients still support it. It is those servers and clients that are vulnerable under insecure fallback. Under normal version negotiation the only weak systems are those that only support 1.2 (presuming higher versions are secure).

Thus, if 1.2 were broken, insecure fallback leaves more legacy systems vulnerable than normal version negotiation does.

In my personal opinion, non-compliant servers are broken, and we should not try to support them. But I understand how reality makes that infeasible.

By normal version negotiation if you mean rfc7507/TLS_FALLBACK_SCSV then even that wont work for legacy systems last updated before April 2015 (publish date of the rfc).

But nonetheless spec authors picked compatibility over security. I would not. Let the legacy insecure tls servers be blocked by the browsers, I say.

I get your position now. Thanks for taking the time to explain it.

> But nonetheless spec authors picked compatibility over security. I would not.

Most of the compatibility compromises don't seem to sacrifice security - except perhaps for increased attack surface, and a more complicated spec (but I'm not sure that leads to a more complicated implementation, so much as it's more thoroughly covering any downgrade dance?)

If there are more security sacrifices to achieve compatibility, I agree with you - that's bad.