QUIC vs TLS security equivalence

[Igor Gatis]

How secure is QUIC compared to TLS (1.2)?

According to Wikipedia page (https://en.wikipedia.org/wiki/QUIC):

 ...was designed to provide security protection equivalent to TLS/SS

Is there any formal proof of equivalence? If yes, what kind of security level?

[Ryan Hamilton]

We believe QUIC is as secure as TLS 1.2 but there is no formal proof. As QUIC moves to standardization, it will be using the TLS 1.3 handshake which will hopefully clarify the situation.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[James Peach]

https://www.sjero.net/pubs/2015_Oakland_QUIC.pdf

This paper discusses various attacks against the QUIC crypto layer and
the comparisons to TLS.

--
James Peach | jor...@gmail.com

[Jim Roskind]

+1 on what Ryan said, as the design was intended to provide pretty equivalent security... in fact... slightly better in general than TLS 1.2 (in subtle ways discussed below). There is also a tiny difference that is fundamental to any 0-RTT effort (with an automatic fallback) as noted in the paper that James Peach cited.  The fact that TLS has gone through formal verification adds greatly to everyone's trust in TLS, though time and again, implementations (rather than specification) have proved to provide weaknesses that were unseen by formal methods.

Some comparitive details about QUIC vs TLS are given below ... if you are really into this.

tl;dr;

I think this is all up-to-date... but others may correct me.

QUIC's subtle caveat (improvement?) centers on QUIC's automatic upgrade to Perfect Forward Secrecy (PFS) after one round trip.  TLS 1.2 supports session resumption, which is generally accomplished by having the client send a copy of secret material protected by a symmetric key known only to the server.  As a result, when session resumption is used, PFS is generally lost using TLS 1.2.  I believe that the proposal for TLS 1.3, which strives to provide performance similar to QUIC's crypto, has remedied that minor (comparitive) weakness.

The 0-RTT connect and send of a request (limited to HTTP GET request(s)) has two consequences (other than the spectacular latency gain impact).  One is that the server does not get to add entropy to to the encryption, and hence PFS is not provided for that initial GET request (as well as possibly the reply... if that reply is formed before the channel can establish PFS in QUIC).  Note that the intent in QUIC was to allow a server to optionally demand that data only be exchanged under PFS (i.e., after a round trip), but I don't believe that option is currently negotiated (not a big deal... since the initial request is generally a top level HTTP GET).

The second consequence is that *ANY* 0-RTT request, which is sent before a channel is established, runs the risk of being black-holed (by UDP blocking at any point on its path).  As a result, the client may be forced to retry the request over TCP (as a fallback), which in turn means that a malicious intermediary (that blocks the ACK of the GET request(s), and the server hello SHLO), could induce the client to retransmit the request once.  The "good news" is that GET requests (the only thing send across a 0-RTT connection) is *supposed* to be idempotent... so a single duplication is not a big deal.  [There are also subtle issues with replay attacks which QUIC originally handled... but I won't go into that here.]

Note that a malicious MITM can cause a similar (single replay inducing) confusion in *any* protocol, including TCP/TLS, but the attacker might have a harder time deciding when to act, and the gains (replay) are not guaranteed.  For instance, if a MITM could guess when the initial GET was sent, it could easily either block all further exchanges (precluding ACKnowledgment of the server's receipt), or simply reset the connection (send RESET messages towards both TCP client and server endpoints <sigh>).   The subtle distinction in this TCP case is that the browser will usually "announce" to the client that a connection has failed, and offer the user the chance to "approve" a retry.  With QUIC, the retry is automatic.  ...but... most browser users would be totally confused by any such TCP/TLS dialog, since they are commonly seen, and the request will surely be sent (a second time).

One other issue to be considered is that PCI credit card handling compliance requires the use of "TLS" (explicitly named in their docs).  As a result, use of  QUIC for handling credit card protection is not yet allowed... but that hurdle should be surpassed when QUIC adopts the upgraded TLS 1.3 standard.

Hope that helps,

Jim

[Bill Cox]

Jim gave a good description.  There is one new-ish goober: an attacker can now do "infinite replay" of 0-RTT packets unless the server takes specific action to prevent replay.  There are also issues related to user authentication at the TLS layer, which should only be an issue if you are using client certs.

Like QUIC, TLS 1.3 looks like it will leave the decision of whether or not to implement infinite replay prevention to the server implementation.  The PSK 0-RTT mode in TLS 1.3 looks like it will enable client certs on the initial 1-RTT handshake, and it will be up to implementations to ensure security of resumption secrets when using 0-RTT PSK resumption, so that the initial 1-RTT client certificate verification covers resumed sessions securely.

Bill