4 ms·

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).
  - brians 9y ago
    Because Google said they'd abandon TLS and use QUIC-CRYPTO unless TLS had 0-RTT in the core standard. And that they insist on splicing the early data onto the TLS stream, smearing H2 traffic across both. Maybe they're right and it'll all be fine—but I expect named bugs in the same family as Triple Handshake.
- readams 9y ago
  0-RTT is sort of inherently vulnerable to replay at the protocol level. By definition you can't do any negotiation, so you can't get rid of replay attacks. 0-RTT is a special feature useful for specific applications where the security implications have been carefully thought through. In other words, expect a large wave of 0-RTT vulnerabilities in the future.
  - comex 9y ago
    Well, TLS 0-RTT is only for resumptions, not a client’s first connection to a server. And the writeup in the parent post suggests requiring the server to enforce atomic single-use resumption tickets, which would in fact get rid of replay attacks - at the cost of effectively prohibiting servers/CDNs from sharing tickets across multiple data centers, since then atomicity would require them to communicate (adding additional latency) before accepting each ticket.
- semantics 9y ago
  There was a talk at last year's Congress about the details of TLS 1.3 and many questions were asked at the end about 0-RTT. Was interesting to hear the cryptographer's, who work on the spec, opinions about that and things like why SNI is not encrypted by default. Link: https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...

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).
- brians 9y ago
  Because Google said they'd abandon TLS and use QUIC-CRYPTO unless TLS had 0-RTT in the core standard. And that they insist on splicing the early data onto the TLS stream, smearing H2 traffic across both. Maybe they're right and it'll all be fine—but I expect named bugs in the same family as Triple Handshake.
readams 9y ago
0-RTT is sort of inherently vulnerable to replay at the protocol level. By definition you can't do any negotiation, so you can't get rid of replay attacks. 0-RTT is a special feature useful for specific applications where the security implications have been carefully thought through. In other words, expect a large wave of 0-RTT vulnerabilities in the future.
- comex 9y ago
  Well, TLS 0-RTT is only for resumptions, not a client’s first connection to a server. And the writeup in the parent post suggests requiring the server to enforce atomic single-use resumption tickets, which would in fact get rid of replay attacks - at the cost of effectively prohibiting servers/CDNs from sharing tickets across multiple data centers, since then atomicity would require them to communicate (adding additional latency) before accepting each ticket.
semantics 9y ago
There was a talk at last year's Congress about the details of TLS 1.3 and many questions were asked at the end about 0-RTT. Was interesting to hear the cryptographer's, who work on the spec, opinions about that and things like why SNI is not encrypted by default. Link: https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...