Re: [quicwg/base-drafts] Add initial threat model to security considerations (#2925)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Just so everyone is clear on what is happening here, I've made a few changes and landed this.  This is obviously a lot of text and it could benefit from more review, but the editors all agreed that it would better to make incremental changes rather than continue to maintain our oldest open PR further.

> +addresses. Such an attack is indistinguishable from the functions performed by a
+NAT.
+
+#### Parameter Negotiation
+
+The entire handshake is cryptographically protected, with the Initial packets
+being encrypted with per-version keys and the Handshake and later packets being
+encrypted with keys derived from the TLS key exchange.  Further, parameter
+negotiation is folded into the TLS transcript and thus provides the same
+security guarantees as ordinary TLS negotiation.  Thus, an attacker can observe
+the client's transport parameters (as long as it knows the QUIC version-specific
+salt) but cannot observe the server's transport parameters and cannot influence
+parameter negotiation.
+
+Connection IDs are unencrypted but integrity protected in all messages.  They
+are not incorporated in the TLS handshake transcript.

Without further elaboration, I have to agree.  

Separately, I think it was Antoine who made some (good) points about authenticating connection IDs more thoroughly that we might want to consider.  Separately though (reminds self to open an issue).

> +client or server Initial messages with invalid messages.  An off-path attacker
+can also mount this attack by racing the Initials.  Once valid Initial messages
+have been exchanged, the remaining handshake messages are protected with the
+handshake keys and an on-path attacker cannot force handshake failure, though
+they can produce a handshake timeout by dropping packets.
+
+An on-path attacker can also replace the addresses of packets on either side and
+therefore cause the client or server to have an incorrect view of the remote
+addresses. Such an attack is indistinguishable from the functions performed by a
+NAT.
+
+#### Parameter Negotiation
+
+The entire handshake is cryptographically protected, with the Initial packets
+being encrypted with per-version keys and the Handshake and later packets being
+encrypted with keys derived from the TLS key exchange.  Further, parameter

Key exchange is correct (the key exchange depends on the message exchange, but it's the key exchange that matters here).

> +
+For the purposes of this discussion, it is assumed that an off-path attacker has
+the ability to observe, modify, and re-inject a packet into the network that
+will reach the destination endpoint prior to the arrival of the original packet
+observed by the attacker.  In other words, an attacker has the ability to
+consistently "win" a race with the legitimate packets between the endpoints,
+potentially causing the original packet to be ignored by the recipient.
+
+It is also assumed that an attacker has the resources necessary to affect NAT
+state, potentially both causing an endpoint to lose its NAT binding, and an
+attacker to obtain the same port for use with its traffic.
+
+In the presence of an off-path attacker, QUIC aims to provide the following
+properties:
+
+1. An off-path attacker can race packets and attempt to become a "limited"

It's first use would seem to work well enough to be definitional.  I'm happy with this as it is.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2925#pullrequestreview-346283685