... | ... | @@ -10,27 +10,25 @@ For a detailed comparison with Google's QUIC, see [[QUIC | this]] page. |
|
|
|:------:|:------:|:------:|:------:|:------:|:------:|
|
|
|
| encryption | **YES** | NO | **YES** | **YES** | **YES** |
|
|
|
| authentication | YES | NO | YES | **YES** | YES |
|
|
|
| authorization | NO | NO | NO | **YES** | NO |
|
|
|
| delayed authentication| NO | NO | NO | **YES** | Maybe |
|
|
|
| Single Sign on | NO | NO | NO | **YES** | NO |
|
|
|
| perfect forward secrecy | optional* | NO | YES** | **YES** | YES*** |
|
|
|
| federated authentication | NO | NO | NO | **YES** | NO |
|
|
|
| stun support for clients | NO | NO | NO | **YES** | NO |
|
|
|
| stun support for clients | NO | NO | NO | **WIP** | NO |
|
|
|
| multistream | NO | **YES** | **YES** | **YES** | **YES** |
|
|
|
| reliable transmission | YES | YES | YES | YES | YES |
|
|
|
| unreliable transmission | NO | **YES** | YES (?) | **YES** | NO (?) |
|
|
|
| unreliable transmission | NO | **YES** | NO | **YES** | NO (?) |
|
|
|
| byte-stream communication | YES | YES | YES | YES | NO |
|
|
|
| message-based communication | NO | **YES** | ?NO? | **YES** | YES (RPC) |
|
|
|
| datagram communication | NO | **YES** | ?NO? | **YES** | YES (RPC) |
|
|
|
| header length (for data) | 38 (+options)| 32 | ?45+?(including UDP) | **21-29** (including UDP)| 52(with UDP)**** |
|
|
|
| multicast support | NO | NO | NO | **Planned** | NO |
|
|
|
| protocol-level proxy| NO | NO | NO | **Planned** | NO |
|
|
|
| compression | NO | NO | **YES** | **Planned** | NO |
|
|
|
| [CRIME](http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29) or [BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) prevention | NO | NO | NO** | yes, **to be tested** | NO |
|
|
|
| Feature | TLS (TCP) | SCTP | QUIC | Fenrir | MinimaLT |
|
|
|
|
|
|
----
|
|
|
* Perfect forward secrecy (PFS) must be explicitly enabled with proper algorithm support in TLS. QUIC provides PFS, but the key for the initial authentication and key exchange is not connection-specific, but is regenerated every couple of minutes. This setup is not perfect but permits QUIC to avoid one RTT and as long as the interval between key regeneration is not long it can be considered secure.
|
|
|
* Perfect forward secrecy (PFS) must be explicitly enabled with proper algorithm support in TLS. QUIC provides PFS, but only after the connection setup, and the key for the initial authentication and key exchange is not connection-specific, but is regenerated every couple of minutes. This setup is not perfect but permits QUIC to avoid one RTT and as long as the interval between key regeneration is not long it can be considered secure.
|
|
|
|
|
|
**QUIC tries to avoid the CRIME/BREACH problems by transmitting a randomly chunked message: instead of filling the udp packet, it chunks the transmission at random and splits everything in multiple packet -- at least that's how I understood it -- While this provides some protection, it should still be possible to rebuild the stream and try to guess if the length is what we are looking for.
|
|
|
|
|
|
***minimaLT perfect forward secrecy is not per-connection, and requires server and dns collaboration. See the [MinimaLT](MinimaLT) page for details.
|
|
|
|
... | ... | |