4 ms·

> I think the point of QUIC is to provide a reliable protocol. I'm not sure if this complaint is relevant. I found it easy to include support for unreliable st

> I think the point of QUIC is to provide a reliable protocol. I'm not sure if this complaint is relevant. I found it easy to include support for unreliable streams in my protocol, I'm just not sure why they did not even try. I heard about a hack-proposal where you could just use a new stream for one packet and then forget about it, but it's not really the same, and I am not sure they did even that. > It's annoying because you need to try decrypting with two different keys, but it simplifies the handshake for both side as the state machine is now super simple The issue I have with it is that now it's the application that needs to be sure not to write too much without an additional round-trip, otherwise you could end up with an amplification attack. I remember reading that there was an additional call to be made by the application just for that. But other simplifications in the handshake are actually great, yes. > if you're talking about 0-RTT, I think replayability is a much bigger problem than forward secrecy as forward secrecy is bound to the server config rotation, so you just need to rotate frequently. Yes, see above. But if I remember correctly rotating keys also makes client unable to use the 0-RTT, so you can't do it too often. QUIC has a weaker PFS than TLS. Still secure, just weaker, and basically disabled unless you explicitely call a key rotation. I am just afraid that the implementations and servers out there will not use that. > How is it a hack? It allows the server to be stateless and it works quite well. How would you make it better? Are we talking about the same thing? I meant the entropy bit. Really dislike it. (Then again, it works, eh...). Yep, my bad, I said "ownership of connection" instead of "ownership od the IP". The ownership of the connection is derived only from the connection id and crypto keys, that's a nice simplification, yes.

baby 9y ago
> I found it easy to include support for unreliable streams in my protocol, I'm just not sure why they did not even try. I heard about a hack-proposal where you could just use a new stream for one packet and then forget about it, but it's not really the same, and I am not sure they did even that. Thinking about it, what would you want for an unreliable stream beside encryption? Isn't DTLS taking care of what you want? > The issue I have with it is that now it's the application that needs to be sure not to write too much without an additional round-trip, otherwise you could end up with an amplification attack. I remember reading that there was an additional call to be made by the application just for that. But other simplifications in the handshake are actually great, yes. So, the server is not going to reply unless the client has proven that it owns the source IP address. This should prevent any amplification attack tied to 0-RTT. Or you mean the kind of amplification attack where the client is tricked into talking to the wrong server? This probably could happen in some scenarios, mmm... I'm thinking that the client wouldn't use 0-RTT without knowing exactly who he's talking to (the cached server configuration is probably tied to the ip:port the client had to connect to the first time around). > if I remember correctly rotating keys also makes client unable to use the 0-RTT, so you can't do it too often. I think 0-RTT targets people connecting to the same website multiple times per day. So I can see scenarios where you would rotate it every day? I'd be interested to know how Google configures its own servers. I just checked, news.google.com has a SSTL of 84:4e:02:00:00:00:00:00 seconds, I think this should be in little endian so it should be around 2 days. This is how much time is left. It's not really informative actually, the SCFG (server config) contains an EXPY field with a unix timestamp indicating 1518350400 (2018/11/02 @ 12:00pm). I realize now that this doesn't tell us much more since it doesn't tell me when the server config was signed :| > QUIC has a weaker PFS than TLS Are you comparing it to TLS 1.3? If you're doing a PSK-based handshake with no key exchange, they should provide the same security properties. > I meant the entropy bit Can you tell me what you're talking about? I don't know the spec by heart. The cookie that the server gives to the client is an encryption of source ip and an expiration date, it just looks opaque to the client but the server can decrypt it and check it.
- floatboth 9y ago
  > what would you want for an unreliable stream Video?
  - baby 9y ago
    That's application specific, not protocol specific. Or maybe I didn't understand your comment? Could you be more specific about what DTLS doesn't provide for streaming that QUIC could have provided?
    - Luker88 9y ago
      As far as I know, neither DTLS nor QUIC provide datagrm transport (as in: managing the beginning/end of user messages, regardless of size), I am not sure if DTLS does unordered delivery (probably not if it simulates a stream), and my favourite is that none can handle transmission of data in a "reliable multicast" fashion. By reliable-multicast I mean something like having a main multicast stream plus a unicast that delivers only the lost data. DTLS multicast also kind of sucks because all clients share the same keys for the MAC, meaning that the clients could spoof the server data towards other clients. Also, I am afraid the Forward Error correction of QUIC is a bit too basic to be really useful, which is why I developed a second library with more flexible FEC than just implementing raid-4 over the network. I am designing my protocol with that transport in mind, because I did not want to limit the user in what he could do. You can do all of this on the application, you can use even multiple stacks, but the upper layers are usually less efficient, more error prone, and we cause a global "reinvent the wheel" movement without even realizing it.
      - baby 9y ago
        > I am not sure if DTLS does unordered delivery That's an interesting point, indeed the RFC[1] seems to support your claim: > DTLS implementations maintain (at least notionally) a > next_receive_seq counter. This counter is initially set to zero. > When a message is received, if its sequence number matches > next_receive_seq, next_receive_seq is incremented and the message is > processed. If the sequence number is less than next_receive_seq, the > message MUST be discarded. If the sequence number is greater than > next_receive_seq, the implementation SHOULD queue the message but MAY > discard it. (This is a simple space/bandwidth tradeoff). [1]: https://tools.ietf.org/html/rfc6347 https://tools.ietf.org/html/rfc6347 > DTLS multicast I'm not seeing mentions of that in the RFC > Forward Error correction of QUIC I'm looking at the QUIC spec and I don't see anything about that, there doesn't seem to be any error correction done in QUIC (perhaps at the UDP level with the checksum you mean?)

baby 9y ago

> I found it easy to include support for unreliable streams in my protocol, I'm just not sure why they did not even try. I heard about a hack-proposal where you could just use a new stream for one packet and then forget about it, but it's not really the same, and I am not sure they did even that. Thinking about it, what would you want for an unreliable stream beside encryption? Isn't DTLS taking care of what you want? > The issue I have with it is that now it's the application that needs to be sure not to write too much without an additional round-trip, otherwise you could end up with an amplification attack. I remember reading that there was an additional call to be made by the application just for that. But other simplifications in the handshake are actually great, yes. So, the server is not going to reply unless the client has proven that it owns the source IP address. This should prevent any amplification attack tied to 0-RTT. Or you mean the kind of amplification attack where the client is tricked into talking to the wrong server? This probably could happen in some scenarios, mmm... I'm thinking that the client wouldn't use 0-RTT without knowing exactly who he's talking to (the cached server configuration is probably tied to the ip:port the client had to connect to the first time around). > if I remember correctly rotating keys also makes client unable to use the 0-RTT, so you can't do it too often. I think 0-RTT targets people connecting to the same website multiple times per day. So I can see scenarios where you would rotate it every day? I'd be interested to know how Google configures its own servers. I just checked, news.google.com has a SSTL of 84:4e:02:00:00:00:00:00 seconds, I think this should be in little endian so it should be around 2 days. This is how much time is left. It's not really informative actually, the SCFG (server config) contains an EXPY field with a unix timestamp indicating 1518350400 (2018/11/02 @ 12:00pm). I realize now that this doesn't tell us much more since it doesn't tell me when the server config was signed :| > QUIC has a weaker PFS than TLS Are you comparing it to TLS 1.3? If you're doing a PSK-based handshake with no key exchange, they should provide the same security properties. > I meant the entropy bit Can you tell me what you're talking about? I don't know the spec by heart. The cookie that the server gives to the client is an encryption of source ip and an expiration date, it just looks opaque to the client but the server can decrypt it and check it.

floatboth 9y ago
> what would you want for an unreliable stream Video?
- baby 9y ago
  That's application specific, not protocol specific. Or maybe I didn't understand your comment? Could you be more specific about what DTLS doesn't provide for streaming that QUIC could have provided?
  - Luker88 9y ago
    As far as I know, neither DTLS nor QUIC provide datagrm transport (as in: managing the beginning/end of user messages, regardless of size), I am not sure if DTLS does unordered delivery (probably not if it simulates a stream), and my favourite is that none can handle transmission of data in a "reliable multicast" fashion. By reliable-multicast I mean something like having a main multicast stream plus a unicast that delivers only the lost data. DTLS multicast also kind of sucks because all clients share the same keys for the MAC, meaning that the clients could spoof the server data towards other clients. Also, I am afraid the Forward Error correction of QUIC is a bit too basic to be really useful, which is why I developed a second library with more flexible FEC than just implementing raid-4 over the network. I am designing my protocol with that transport in mind, because I did not want to limit the user in what he could do. You can do all of this on the application, you can use even multiple stacks, but the upper layers are usually less efficient, more error prone, and we cause a global "reinvent the wheel" movement without even realizing it.
    - baby 9y ago
      > I am not sure if DTLS does unordered delivery That's an interesting point, indeed the RFC[1] seems to support your claim: > DTLS implementations maintain (at least notionally) a > next_receive_seq counter. This counter is initially set to zero. > When a message is received, if its sequence number matches > next_receive_seq, next_receive_seq is incremented and the message is > processed. If the sequence number is less than next_receive_seq, the > message MUST be discarded. If the sequence number is greater than > next_receive_seq, the implementation SHOULD queue the message but MAY > discard it. (This is a simple space/bandwidth tradeoff). [1]: https://tools.ietf.org/html/rfc6347 https://tools.ietf.org/html/rfc6347 > DTLS multicast I'm not seeing mentions of that in the RFC > Forward Error correction of QUIC I'm looking at the QUIC spec and I don't see anything about that, there doesn't seem to be any error correction done in QUIC (perhaps at the UDP level with the checksum you mean?)