3 ms·

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 m

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.

rocqua 9y ago
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.
- wav-part 9y ago
  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.
  - MaulingMonkey 9y ago
    > 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.

rocqua 9y ago

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.

wav-part 9y ago
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.
- MaulingMonkey 9y ago
  > 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.