More Apparent Randomization for QUIC
draft-thomson-quic-grease-00

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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