Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

AEAD all packets. Fixed #693, Fixes #840. #844

Merged
merged 2 commits into from Oct 10, 2017
Merged

AEAD all packets. Fixed #693, Fixes #840. #844

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a0c571b
AEAD all packets. Fixed #693, Fixes #840.
ekr Oct 9, 2017
cf60548
Update salt. This salt isn't random but rather is the git hash of
ekr Oct 9, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
103 changes: 36 additions & 67 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -632,6 +632,32 @@ QUIC uses HKDF with the same hash function negotiated by TLS for
key derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the
SHA-256 hash function is used.

### Cleartext Packet Secrets {#cleartext-secrets}

Cleartext packets are protected with secrets derived from the client's
connection ID. Specifically:

~~~
quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639

cleartext_secret = HKDF-Extract(quic_version_1_salt,
client_connection_id)

client_cleartext_secret =
HKDF-Expand-Label(cleartext_secret,
"QUIC client cleartext Secret",
"", Hash.length)
server_cleartext_secret =
HKDF-Expand-Label(cleartext_secret,
"QUIC server cleartext Secret",
"", Hash.length)
~~~

Future versions of QUIC SHOULD generate a new salt value, thus ensuring
that the keys are different for each version of QUIC. This prevents
a middlebox that only recognizes one version of QUIC from seeing or
modifying the contents of cleartext packets from future versions.


### 0-RTT Secret {#zero-rtt-secrets}

Expand Down Expand Up @@ -758,8 +784,11 @@ used for QUIC packet protection is AEAD that is negotiated for use with the TLS
connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the
AEAD_AES_128_GCM function is used.

Regular QUIC packets are protected by an AEAD algorithm {{!RFC5116}}. Version
negotiation and public reset packets are not protected.
All QUIC packets other than version negotiation and public reset packets are
protected with an AEAD algorithm {{!RFC5116}}. Cleartext packets are protected
with the AEAD_AES_128_GCM and a key derived from the client's connection ID.
This provides protection against off-path attackers and robustness against
QUIC version unaware middleboxes, but not against on-path attackers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that there will be at some point a request to support "QUIC for IOT" and use AES 128 with CCM 8. But we are not there yet, and the IOT folks would just have to create their own version...

Once TLS has provided a key, the contents of regular QUIC packets immediately
after any TLS messages have been sent are protected by the AEAD selected by TLS.
Expand Down Expand Up @@ -838,64 +867,6 @@ number gaps on connection ID transitions. That secret is computed as:
"", Hash.length)
~~~

# Unprotected Packets

QUIC adds an integrity check to all cleartext packets. Cleartext packets are
not protected by the negotiated AEAD (see {{packet-protection}}), but instead
include an integrity check. This check does not prevent the packet from being
altered, it exists for added resilience against data corruption and to provide
added assurance that the sender intends to use QUIC.

Cleartext packets all use the long form of the QUIC header and so will include a
version number. For this version of QUIC, the integrity check uses the 64-bit
FNV-1a hash (see {{fnv1a}}). The output of this hash is appended to the payload
of the packet.

The integrity check algorithm MAY change for other versions of the protocol.


## Integrity Check Processing

An endpoint sending a packet that has a long header and a type that does not
indicate that the packet will be protected (that is, 0-RTT Encrypted (0x05),
1-RTT Encrypted (key phase 0) (0x06), or 1-RTT Encrypted (key phase 1) (0x07))
first constructs the packet that it sends without the integrity check.

The sender then calculates the integrity check over the entire packet, starting
from the type field. The output of the hash is appended to the packet.

A receiver that receives an unprotected packet first checks that the version is
correct, then removes the trailing 8 octets. It calculates the integrity check
over the remainder of the packet. Unprotected packets that do not contain a
valid integrity check MUST be discarded.


## The 64-bit FNV-1a Algorithm {#fnv1a}

QUIC uses the 64-bit version of the alternative Fowler/Noll/Vo hash (FNV-1a)
{{?FNV=I-D.eastlake-fnv}}.

FNV-1a can be expressed in pseudocode as:

~~~
hash := offset basis
for each input octet:
hash := hash XOR input octet
hash := hash * prime
~~~

That is, a 64-bit unsigned integer is initialized with an offset basis. Then,
for each octet of the input, the exclusive binary OR of the value is taken, then
multiplied by a prime. Any overflow from multiplication is discarded.

The offset basis for the 64-bit FNV-1a is the decimal value 14695981039346656037
(in hex, 0xcbf29ce484222325). The prime is 1099511628211 (in hex,
0x100000001b3; or as an expression 2^40 + 2^8 + 0xb3).

Once all octets have been processed in this fashion, the final integer value is
encoded as 8 octets in network byte order.


# Key Phases

As TLS reports the availability of 0-RTT and 1-RTT keys, new keying material can
Expand Down Expand Up @@ -924,12 +895,10 @@ ensure that TLS handshake messages are sent with the correct packet protection.

## Packet Protection for the TLS Handshake {#cleartext-hs}

The initial exchange of packets are sent without protection. These packets use
a cleartext packet type.

TLS handshake messages MUST NOT be protected using QUIC packet protection. All
TLS handshake messages up to the TLS Finished message sent by either endpoint
use cleartext packets.
The initial exchange of packets are sent using a cleartext packet type
and AEAD-protected using the cleartext key generated as described in
{{cleartext-secrets}}. All TLS handshake messages up to the TLS
Finished message sent by either endpoint use cleartext packets.

Any TLS handshake messages that are sent after completing the TLS handshake do
not need special packet protection rules. Packets containing these messages use
Expand All @@ -944,7 +913,7 @@ client in cleartext packets.
### Initial Key Transitions {#first-keys}

Once the TLS handshake is complete, keying material is exported from TLS and
QUIC packet protection commences.
used to protect QUIC packets.

Packets protected with 1-RTT keys initially have a KEY_PHASE bit set to 0. This
bit inverts with each subsequent key update (see {{key-update}}).
Expand Down
16 changes: 11 additions & 5 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -555,8 +555,11 @@ Cleartext packets are sent during the handshake prior to key negotiation.

All cleartext packets contain the current QUIC version in the version field.

The payload of cleartext packets also includes an integrity check, which is
described in {{QUIC-TLS}}.
In order to prevent tampering by version-unaware middleboxes, Cleartext
packets are protected with a connection and version specific key, as
described in {{QUIC-TLS}}. This protection does not provide confidentiality
or integrity against on-path attackers, but provides some level of
protection against off-path attackers.


### Client Initial Packet {#packet-client-initial}
Expand Down Expand Up @@ -926,8 +929,9 @@ Version Negotiation packet.
A client MUST ignore a Version Negotiation packet that lists the client's chosen
version.

Version negotiation uses unprotected data. The result of the negotiation MUST be
revalidated as part of the cryptographic handshake (see {{version-validation}}).
Version negotiation packets have no cryptographic protection. The
result of the negotiation MUST be revalidated as part of the
cryptographic handshake (see {{version-validation}}).

### Using Reserved Versions

Expand Down Expand Up @@ -1638,6 +1642,8 @@ connection that is reset by revealing the Stateless Reset Token cannot be
reused for new connections at the same server without first changing to use a
different static key or server identifier.

Note that Stateless Reset messages do not have any cryptographic protection.


# Frame Types and Formats

Expand Down Expand Up @@ -3316,7 +3322,7 @@ Issue and pull request numbers are listed with a leading octothorp.

## Since draft-ietf-quic-transport-06

Nothing yet.
- Replaced FNV-1a with AES-GCM for all "Cleartext" packets.

## Since draft-ietf-quic-transport-05

Expand Down