From 5edec0bbdc72c4d5210af36ca3bac1f22d0a5654 Mon Sep 17 00:00:00 2001 From: EKR Date: Wed, 3 May 2017 10:15:47 -0700 Subject: [PATCH] Remove the explicit packet number gap in favor of one computed based on a shared secret. --- draft-ietf-quic-tls.md | 10 +++++++ draft-ietf-quic-transport.md | 54 +++++++++++++++++++----------------- 2 files changed, 39 insertions(+), 25 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 0ee97ac21c..a7ea4cde15 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -820,6 +820,16 @@ protocol error in a peer or an attack. The truncated packet number encoding used in QUIC can cause packet numbers to be decoded incorrectly if they are delayed significantly. +## Packet Number Gaps + +{{QUIC-TRANSPORT}}; Section 7.5.1.1 also requires a secret to compute packet +number gaps on connection ID transitions. That secret is computed as: + +~~~ + packet_number_secret + = TLS-Exporter("EXPORTER-QUIC Packet Number Secret" + "", Hash.length) +~~~ # Unprotected Packets diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a6b55cc969..119b7e6ad2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1257,22 +1257,21 @@ way to retry them. ### Privacy Implications of Connection Migration {#migration-linkability} -Using a stable connection ID on multiple network paths allows a passive observer -to correlate activity between those paths. A client that moves between networks -might not wish to have their activity correlated by any entity other than a -server. - -The NEW_CONNECTION_ID message can be sent by a server to provide an unlinkable -connection ID for use in case the client wishes to explicitly break linkability +Using a stable connection ID on multiple network paths allows a +passive observer to correlate activity between those paths. A client +that moves between networks might not wish to have their activity +correlated by any entity other than a server. The NEW_CONNECTION_ID +message can be sent by a server to provide an unlinkable connection ID +for use in case the client wishes to explicitly break linkability between two points of network attachment. -The NEW_CONNECTION_ID message includes a connection ID that the client can use -for packets on the current connection. This message also includes packet number -gap, which is the number of packet numbers that the client skips when using the -new connection ID. Without this, the packet number field in the header might be -used to link activity across networks. A server MUST provide a 32-bit value for -the packet number gap field that is indistinguishable from random to a passive -observer. +A client which wishes to break linkability upon changing networks MUST +use the NEW_CONNECTION_ID as well as incrementing the packet sequence +number by an externally unpredictable value computed as described in +{{packet-number-gap}}. Packet number gaps are cumulative. A client +might skip connection IDs, but it MUST ensure that it applies the +associated packet number gaps in addition to the packet number gap +associated with the connection ID that it does use. A client might need to send packets on multiple networks without receiving any response from the server. To ensure that the client is not linkable across each @@ -1281,10 +1280,6 @@ network. To support this, a server sends multiple NEW_CONNECTION_ID messages. Each NEW_CONNECTION_ID is marked with a sequence number. Connection IDs MUST be used in the order in which they are numbered. -Packet number gaps are cumulative. A client might skip connection IDs, but it -MUST ensure that it applies the associated packet number gaps in addition to the -packet number gap associated with the connection ID that it does use. - A server that receives a packet that is marked with a new connection ID recovers the packet number by adding the cumulative packet number gap to its expected packet number. A server SHOULD discard packets that contain a smaller gap than @@ -1296,6 +1291,22 @@ connection ID, it should expect packets on the new connection ID to start at 18. A packet with the new connection ID and a packet number of 17 is discarded as being in error. +#### Packet Number Gap + +In order to avoid linkage, the packet number gap MUST be externally +indistinguishable from random. The packet number gap for a connection +ID with sequence number is computed by encoding the sequence number +as a 32-bit integer in big-endian format, and then computing: + +~~~ +Gap = HKDF-Expand-Label(packet_number_secret, + "QUIC packet sequence gap", sequence, 4) +~~~ + +The output of HKDF-Expand-Label is interpreted as a big-endian +number. "packet_number_secret" is derived from the TLS key exchange, +as described in {{QUIC-TLS}} Section 5.6. + ### Address Validation for Migrated Connections @@ -1937,8 +1948,6 @@ The NEW_CONNECTION_ID is as follows: + Connection ID (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Packet Number Gap (32) | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields are: @@ -1956,11 +1965,6 @@ Connection ID: : A 64-bit connection ID. -Packet Number Gap: - -: The number of packets to skip when using the connection ID. Packet number - gaps are cumulative, see {{migration-linkability}}. - ## CONNECTION_CLOSE frame {#frame-connection-close}