Re: On the relation between QUIC documents

Mirja K├╝hlewind <> Wed, 01 August 2018 12:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EC43127332 for <>; Wed, 1 Aug 2018 05:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H8OfNsdEtZtQ for <>; Wed, 1 Aug 2018 05:54:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 183AA130DFC for <>; Wed, 1 Aug 2018 05:54:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41gYCx4hJxz15K3S; Wed, 1 Aug 2018 14:54:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PH2eZA-58OTK; Wed, 1 Aug 2018 14:54:20 +0200 (CEST)
X-MtScore: NO score=0
Received: from [] ( []) by (Postfix) with ESMTPSA; Wed, 1 Aug 2018 14:54:20 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: On the relation between QUIC documents
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>
In-Reply-To: <>
Date: Wed, 1 Aug 2018 14:54:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Mathias Hall-Andersen <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Aug 2018 12:54:26 -0000

Hi Mathias,

the group concluded a while ago that version 1 (or whatever this first IETF version will be called) of QUIC will use TLS and using a different encryption scheme will require to specify a new QUIC version. However, the TLS part is still in an separate document to make the specification on a new version with just a different crypto as easy as possible.

However, I do agree that there are some cases where the separation could be even more clear (e.g. the key phase bit is an example) and maybe requirements should be spelled out separately in order to make is easier to evolve to a new crypto scheme when needed. The PNE, however, is in my opinion separate enough from the payload encryption that is should stay in the transport draft itself.


> Am 12.07.2018 um 20:56 schrieb Mathias Hall-Andersen <>rg>:
> I wish to discuss the relation between QUIC design documents, 
> as well as the relation between QUIC and TLS more generally.
> Currently the draft-ietf-quic-transport and draft-ietf-quic-tls documents both depend on each other,
> the remainder of this text details my rationale for desiring a more
> clear delegation of responsibilities between these two documents:
> I suggest that draft-ietf-quic-transport should describe a (semi formal)
> interface between the transport component and the cryptographic component, 
> by listing a series of criteria for the handshake and the packet protection..
> The draft-ietf-quic-tls would be an implementation meeting these criteria and
> the draft-ietf-quic-transport should reference draft-ietf-quic-tls as an example.
> Essentially the standard would become a version of quic-transport instantiated with a version of quic-tls.
> The advantages of having a more clear relation between the two documents include:
> 1. Allowing the documents to evolve independently,
>    by having changes to the internals of the TLS document not affect the transport document.
> 2. Encourage people to create implementations which better separate the two,
>    which might make it easier to swap in different / future implementations of the handshake & packet protection.
> 3. Clearly stating what properties we expect the handshake and packet protection to satisfy.
>    This might also make formal analysis easier, by showing that the TLS instantiation satisfies these properties.
>    We might even be able to state what a handshake should satisfy formally in a proof assistant.
> 4. Permitting the construction of alternate handshakes satisfying the criteria.
> I have compiled a list of some sections which currently violate this relation:
> ------
> The "Key Phase Bit" is mentioned in the draft-ietf-quic-transport document,
> but not described herein, instead the document refers to draft-ietf-quic-tls.
> It is unclear if this bit has any definition outside a QUIC + TLS context,
> instead it could be a "PACKET_PROTECTION_FLAG" bit in the transport document,
> which is used as the "KEY_PHASE" bit in the QUIC-TLS instantiation of
> the handshake & packet protection.
> ------
> "The packet number has confidentiality protection separate from
>  packet protection, as described in Section 5.6 of [QUIC-TLS]."
> Could be replaced with something like:
> "The protector MAY provide confidentiality for packet numbers.
>  This protection is separate from the packet protection and SHOULD achieve the following: XYZ.
>  Example:
>  The TLS based handshake [QUIC-TLS], section is one example which satisfies the aforementioned properties."
> ------
> "The payload is protected using authenticated encryption.
>  [QUIC-TLS] describes packet protection in detail.  After decryption, the
>  plaintext consists of a sequence of frames, as described in
>  Section 5."
> Might become:
> "The payload is protected using authenticated encryption
>  offering at least 128-bits of security, using the packet header as AD and ...
>  Example:
>  [QUIC-TLS], section A.B.C, describes in detail an implementation satisfying these criteria"
> ------
> "For the most part, the cryptographic handshake protocol [QUIC-TLS] is
>  responsible for detecting tampering during the handshake, though
>  additional validation is required for version negotiation (see Section 6.6.4)."
> QUIC-TLS is referred to as THE cryptographic handshake,instead we should
> aim to have a section more in the vain of:
> "The cryptographic handshake MUST ensure that XYZ
>  Additional validation is required for version negotiation (see Section 6.6.4)."
> Examples of XYZ, might include the authenticity of all data sent in CRYPTO frames.
> ------
> "The Initial packet is protected by Initial keys as described in
> [QUIC-TLS]."
> This should be part of the description of the packet protect
> requirements, something like:
> "The packet protector MAY make an effort to obfuscate the contents of initial packets,
>  to help prevent version aware middleboxes from parsing...."
> - Mathias