5 ms·

> Note, we currently do not have 0-RTT data support. That is like the most exiting feature of TLS 1.3.

ninju 9y ago
and exciting :-)
daenney 9y ago
It's also a contested one as it can open one up to issues. Some of these are detailed here, for example: https://github.com/tlswg/tls13-spec/issues/1001 https://github.com/tlswg/tls13-spec/issues/1001 It seems prudent to not support something like 0-RTT until the consequences of it are well understood and an informed decision can be made on if the increased speed is worth its trade-offs and how best to protect the data in transit from its potential issues.
- derefr 9y ago
  How is anyone going to understand the consequences unless someone actually implements it in a stack (behind a feature-flag) that people are then encouraged to go play with—exactly as is being done here with TLS 1.3 itself? In other words: wouldn't 0-RTT be the thing it'd be most interesting to see a limited-opt-in real-world test of? Why bother testing TLS 1.3 without it?
  - daenney 9y ago
    > How is anyone going to understand the consequences unless someone actually implements it in a stack (behind a feature-flag) that people are then encouraged to go play with—exactly as is being done here with TLS 1.3 itself? If you read the issue that I linked, it's already been tested and a number of flaws found. It has also been tested by others who've also verified the issue with potential replay attacks. Putting something that is known to already have flaws behind a feature flag so others can, potentially unknowingly, start using it doesn't seem like a useful exercise to me and does little to gain additional data on the matter. Once the existing issues are resolved it might be more interesting to try what you're suggesting.
  - brians 9y ago
    Oh, it's badly flawed enough that it's visible without testing. The way some TLS libraries are implementing it---fusing the early data with the regular stream---is a recipe for Triple Handshake style bugs. What's going to be interesting about broad rollout of 1.3 without 0RTT is the effect of middle boxes and other crud trying to parse streams as they forward.
  - throwaway2048 9y ago
    Some people will rush headlong into the new and shiny features, they always do. Let them take the lumps.
valarauca1 9y ago
Replay attacks are a big issue with 0-RTT. Until they get resolved it is best to not support it as TLSv1.3 loses some of its security guarantees.
- rrdharan 9y ago
  Found a nice write-up of these issues here for anyone else interested: https://github.com/tlswg/tls13-spec/issues/1001 https://github.com/tlswg/tls13-spec/issues/1001 TLS 1.3 0-RTT is not secure by default, but it is possible to provide both anti-replay and forward-secrecy properties for 0-RTT data with workarounds. As long as TLS 1.3 is not secure by default it is likely to lead to exploitable vulnerabilities that can only be fixed at the application level, distant from the cause. In general, it is also very challenging to fix applications to be idempotent and side-effect free. Instead of shifting the problem to applications, we should strongly consider modifying the TLS 1.3 draft to make TLS 0-RTT secure by default, at least against replays. While Gillmor-style retry attacks will persist, these attacks may be mitigated with reasonable client behavior, and in many cases the existing client behavior is already fault tolerant.
  - MichaelGG 9y ago
    Why would TLS add an insecure by default feature? Hasn't security been a problem for TLS historically? Or is this aimed at higher end providers that can be trusted to only enable it for certain things? (Like, Google Search might benefit from it, and replays probably aren't an issue?)
    - readams 9y ago
      0-RTT is not automatically enabled. You need to opt in.
      - MrRadar 9y ago
        Like if you're a CloudFlare customer? https://blog.cloudflare.com/introducing-0-rtt/ https://blog.cloudflare.com/introducing-0-rtt/ They enable it for TLS 1.3 by default for "GET requests with no query parameters" and place at least some of the onus on the origin server to detect replays (via a "Cf-0rtt-Unique" HTTP header).
baby 9y ago
You mean the most controversial.
- hinkley 9y ago
  Pirates are exciting. So are barbarian hordes, lions, blood-crazed sharks, and letters from the IRS. Generally you don't want your software to be exciting. Not all of my peers agree
ecesena 9y ago
From [1]: > 0-RTT data can be replayed If you want to allow 0-RTT, you need a way to specify which [api] calls are safe to run in 0-RTT, and which aren't. Which in turn requires a sort of scheduler for calls, making your network stack pretty complex. In the post, for example, Facebook controls both the client and the server, so they can do that, but it's a non trivial problem for a general purpose library/implementation. [1] https://code.facebook.com/posts/608854979307125/building-zero-protocol-for-fast-secure-mobile-connections/ https://code.facebook.com/posts/608854979307125/building-zer... (Section Time-bound 0-RTT data)
- readams 9y ago
  Even Facebook still requires the developers to manually declare things safe/unsafe for 0-RTT, and frankly the requirements for doing this securely are very subtle. This is a massive footgun.
mtgx 9y ago
And probably the one to be most badly implemented.

and exciting :-)

It's also a contested one as it can open one up to issues. Some of these are detailed here, for example: https://github.com/tlswg/tls13-spec/issues/1001 https://github.com/tlswg/tls13-spec/issues/1001 It seems prudent to not support something like 0-RTT until the consequences of it are well understood and an informed decision can be made on if the increased speed is worth its trade-offs and how best to protect the data in transit from its potential issues.

derefr 9y ago
How is anyone going to understand the consequences unless someone actually implements it in a stack (behind a feature-flag) that people are then encouraged to go play with—exactly as is being done here with TLS 1.3 itself? In other words: wouldn't 0-RTT be the thing it'd be most interesting to see a limited-opt-in real-world test of? Why bother testing TLS 1.3 without it?
- daenney 9y ago
  > How is anyone going to understand the consequences unless someone actually implements it in a stack (behind a feature-flag) that people are then encouraged to go play with—exactly as is being done here with TLS 1.3 itself? If you read the issue that I linked, it's already been tested and a number of flaws found. It has also been tested by others who've also verified the issue with potential replay attacks. Putting something that is known to already have flaws behind a feature flag so others can, potentially unknowingly, start using it doesn't seem like a useful exercise to me and does little to gain additional data on the matter. Once the existing issues are resolved it might be more interesting to try what you're suggesting.
- brians 9y ago
  Oh, it's badly flawed enough that it's visible without testing. The way some TLS libraries are implementing it---fusing the early data with the regular stream---is a recipe for Triple Handshake style bugs. What's going to be interesting about broad rollout of 1.3 without 0RTT is the effect of middle boxes and other crud trying to parse streams as they forward.
- throwaway2048 9y ago
  Some people will rush headlong into the new and shiny features, they always do. Let them take the lumps.

valarauca1 9y ago

Replay attacks are a big issue with 0-RTT. Until they get resolved it is best to not support it as TLSv1.3 loses some of its security guarantees.

rrdharan 9y ago
Found a nice write-up of these issues here for anyone else interested: https://github.com/tlswg/tls13-spec/issues/1001 https://github.com/tlswg/tls13-spec/issues/1001 TLS 1.3 0-RTT is not secure by default, but it is possible to provide both anti-replay and forward-secrecy properties for 0-RTT data with workarounds. As long as TLS 1.3 is not secure by default it is likely to lead to exploitable vulnerabilities that can only be fixed at the application level, distant from the cause. In general, it is also very challenging to fix applications to be idempotent and side-effect free. Instead of shifting the problem to applications, we should strongly consider modifying the TLS 1.3 draft to make TLS 0-RTT secure by default, at least against replays. While Gillmor-style retry attacks will persist, these attacks may be mitigated with reasonable client behavior, and in many cases the existing client behavior is already fault tolerant.
- MichaelGG 9y ago
  Why would TLS add an insecure by default feature? Hasn't security been a problem for TLS historically? Or is this aimed at higher end providers that can be trusted to only enable it for certain things? (Like, Google Search might benefit from it, and replays probably aren't an issue?)
  - readams 9y ago
    0-RTT is not automatically enabled. You need to opt in.
    - MrRadar 9y ago
      Like if you're a CloudFlare customer? https://blog.cloudflare.com/introducing-0-rtt/ https://blog.cloudflare.com/introducing-0-rtt/ They enable it for TLS 1.3 by default for "GET requests with no query parameters" and place at least some of the onus on the origin server to detect replays (via a "Cf-0rtt-Unique" HTTP header).

baby 9y ago

You mean the most controversial.

hinkley 9y ago
Pirates are exciting. So are barbarian hordes, lions, blood-crazed sharks, and letters from the IRS. Generally you don't want your software to be exciting. Not all of my peers agree

ecesena 9y ago

From [1]: > 0-RTT data can be replayed If you want to allow 0-RTT, you need a way to specify which [api] calls are safe to run in 0-RTT, and which aren't. Which in turn requires a sort of scheduler for calls, making your network stack pretty complex. In the post, for example, Facebook controls both the client and the server, so they can do that, but it's a non trivial problem for a general purpose library/implementation. [1] https://code.facebook.com/posts/608854979307125/building-zero-protocol-for-fast-secure-mobile-connections/ https://code.facebook.com/posts/608854979307125/building-zer... (Section Time-bound 0-RTT data)

readams 9y ago
Even Facebook still requires the developers to manually declare things safe/unsafe for 0-RTT, and frankly the requirements for doing this securely are very subtle. This is a massive footgun.

mtgx 9y ago

And probably the one to be most badly implemented.