More Apparent Randomization for QUIC
draft-thomson-quic-grease-00
|
Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2017-12-06
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
html
bibtex
|
Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
QUIC M. Thomson
Internet-Draft Mozilla
Intended status: Informational December 07, 2017
Expires: June 10, 2018
More Apparent Randomization for QUIC
draft-thomson-quic-grease-00
Abstract
Options for creating more apparent randomization in the QUIC header
are discussed.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 10, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Thomson Expires June 10, 2018 [Page 1]
Internet-Draft More Apparent Randomization for QUIC December 2017
1. More Grease for QUIC
The QUIC invariants draft [INVARIANTS] commits QUIC [QUIC] to a small
set of traits that are intended to remain stable across all version
of QUIC. However, there are some protocol traits in QUIC version 1
[QUIC] that we do that remain readable.
This note explores a few options for protecting QUIC against casual
inspection by entities other than the endpoints participating in the
connection. These techniques are aimed espectially at making any
form of inspection considerably more difficult if the QUIC version of
a packet is unknown.
The intent of applying this protection is to encourage the use of
protocol fields that are intentionally designed to be readable to
non-participating entities (see also [SIGNALS]). For those fields
that can be recovered without access to negotiated cryptographic
keys, the intent is to create an incentive to implement version-
specific handling rather than to assume that certain properties don't
change between versions.
2. Overall Design
Protocol fields that deploy with predictable values or a limited
range of values can ossify. Ossification is the effect whereby the
use of values in a way that is contradictory to established patterns
triggers adverse reactions from the network. Usually, this is a
result of middleboxes having developed assumptions about how
protocols operate.
The idea that ossification actively prevents the deployment of
modified protocols remains a little contentious in the community. On
the other hand, we have plenty of evidence from TLS deployment to
suggest that this happens. Appendix D.4 of [TLS13] describes an
example of ossification and describes the measures that were
necessary to counteract it.
If it is possible to provide a measure of protection against protocol
ossification without inordinate expense, then it is the view of at
least this author that doing so would have some potential value.
Provided the costs are indeed low enough
This describes changes to some of the version-specific fields in QUIC
version 1 [QUIC]. Any invariant [INVARIANTS] would not be affected
by this change.
The simplest defense against ossification is to apply a reversible
permutation to these values. A pseudo-random function (PRP) is the
Thomson Expires June 10, 2018 [Page 2]
Internet-Draft More Apparent Randomization for QUIC December 2017
obvious choice. If the key of that function is only known to
endpoints, then the values will be readily accessible to endpoints.
3. Keying
There are two different contexts in which we might consider applying
this sort of protection, and the keys we can use differ.
QUIC already has the tools necessary to derive keys. Handshake
packets use a key that is derived from a combination of a version-
specific key (or salt) and the connection ID. A similar approach
Show full document text