On the relation between QUIC documents

Mathias Hall-Andersen <mathias.hall-andersen@nccgroup.trust> Thu, 12 July 2018 18:56 UTC

Return-Path: <mathias.hall-andersen@nccgroup.trust>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F17130DF2 for <quic@ietfa.amsl.com>; Thu, 12 Jul 2018 11:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nccgroup.trust
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cq3Uyc1P8yui for <quic@ietfa.amsl.com>; Thu, 12 Jul 2018 11:56:28 -0700 (PDT)
Received: from eu-smtp-delivery-170.mimecast.com (eu-smtp-delivery-170.mimecast.com [146.101.78.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EDE5130E61 for <quic@ietf.org>; Thu, 12 Jul 2018 11:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nccgroup.trust; s=dkim20160329; t=1531421786; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=jHYN9xFYKa4vdmO/n8xc8gQGzUPQVEdcQGYAl6bqxIg=; b=AkFqPaTlEJUBTFQntioAnVPYYcMWjcMm3ovSnoIL3Z0e1EmC/T3qMG/MUdXdB6sVr9sJkX3lw09JeppbBFXXDU5v1CmslE2hbghWnsLZnxxukUu1N1hiwORqhUYOOVcUSBtgOoPVdTvtwvwKJ9w1oCZncRpdcDXre+fH29WrS/c=
Received: from lon1srvpgp01p.nccgroup.local (lonrelay01.nccgroup.trust [5.148.32.148]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-127-GpWhQSPbN46hxJH9g-i9Bw-1; Thu, 12 Jul 2018 19:56:25 +0100
Received: from MANDBSEXCH03.nccgroup.local ([10.1.120.104]) by lon1srvpgp01p.nccgroup.local (PGP Universal service); Thu, 12 Jul 2018 19:56:25 +0100
X-PGP-Universal: processed; by lon1srvpgp01p.nccgroup.local on Thu, 12 Jul 2018 19:56:25 +0100
Received: from [10.133.160.49] (10.1.120.175) by MANDBSEXCH03.nccgroup.local (10.1.120.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 12 Jul 2018 19:56:24 +0100
To: <quic@ietf.org>
From: Mathias Hall-Andersen <mathias.hall-andersen@nccgroup.trust>
Subject: On the relation between QUIC documents
Openpgp: preference=signencrypt
Autocrypt: addr=mathias.hall-andersen@nccgroup.trust; keydata= xsBNBFrorZABCACXm2Jvfj2L5Gt6SsAAaM5psxgjSB+p9Whl9HHJBH1xmHe4+dreXwrW4NEX aph0pm8UrpxQB7BPlst5Nb7ssHOe9Sbr2hSJY5AI0JJpq/rX8EPEErEd6hKMq2n/lkH9YJLH L3F9mEK9MiypzuF55LM5BI5eHwyZEucpwOun9DfK/2MyYrqrhH97HTkMO8Vx3MpmP4/GVpby lx6V02ay2ndwbNdBoamF/CwtShEZrpILaFOZjKDV7L+1RsIxyi2YUYCN1A16mZlk+lFR5RvW sm7EfMpysXpmfc07zs3JItG5WqO4p8oB1RMwFAID2I/cXV0eLh211B+MmFLHnx2cPj2tABEB AAHNPE1hdGhpYXMgSGFsbC1BbmRlcnNlbiA8bWF0aGlhcy5oYWxsLWFuZGVyc2VuQG5jY2dy b3VwLnRydXN0PsLAlAQTAQgAPhYhBAMx48G1Gp008HPB1crOs12B00OABQJa6K2QAhsDBQkD w5nwBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEMrOs12B00OABPAH/ijAL+ybZUHyqjMo AlvFeuALXoHKI5vYbkOms1FoDBRjTBSrlLwq7dj4wGmcSsoO554e9OIr6qwzwe3sv2Bg3wOL fewwgvRywAmVNioFECU53QrqiamwnQAKPT+pEl7StCo6SHfllW7x7c+KsK+/PD/1GfuZFPj9 toblvg8/kYVwTCVMpZ9jNJRCeXgP0ZkNuwLusgF5IHxIm9H2Gum3VU5Qsqjb8Sek5BfBUBmx RdBM0KKprzvGpD4WdyaWxGXogjH7VBR6ArIEnPlNka+Kq1tFAAkLwmqRyrUVrbzynVoq5LGi vZ1oZMBsB5UVWLruc0+1EVw7K/aLwH45m8mFvnrOwM0EWuitkAEMAKoXA8y6opgv/QhobBIz i7qnzcKUOxE1LhrYYxjesQUuH1GrmjMlO40EpHxVZcfu7La9eKK2f2Swk5ib0jox6yJnKoG1 7w7oI6KoDaozg6FK6QWisEOpMvpugFMtd/IQzyNZNCnD5RPcraxQzMqP+YKvc+bPpyqq/S2l EhS44uTcqIQuEbwPIbvhC4ZR9Xe5GsOzj9MoKhFzwDDrT7fK1zUsQPGReIrpPjQpIAY2pfI2 5N8Bq4w5lz5oSU6Khy2Tv9BOnzLrL8x6R24hKNeyJR6vOCCjooPBxRfKlf8jPLnawZXR4Xmb opBM8Ev1iD+6p3l67dCaAwF/HOJ/5lvfZfiCq70SQZrBzYmphdPUaXhKAejpwGSjbPTbJ/eE QOlBfP6HXcHizloBGQiC7kOCp/UtL9nVr2lH7411t7DSsr4hy8xwRMVOaYzHVXgMGAduMjnW rV1epTlNXq0TFWNa9lC8ivU8RAAZkaJ2XZH6MmXNVqmbBOB2X5Pboc3fQF3xTQARAQABwsB8 BBgBCAAmFiEEAzHjwbUanTTwc8HVys6zXYHTQ4AFAlrorZACGwwFCQPDmfAACgkQys6zXYHT Q4Dofgf/VVPRYx92YakFCdGUjIM+dvju/nPw0A84uZURzeLZn/cARJCj6d5EYZWMiO9GOay7 6+JNZQ+Ie3KQbU5ByKmNJ6omWaZcsXaC3iDcTcFIasTemAfBMg2GKmR3+UkJ12S30iKC1J8j /1xSt0H6Ub6cFAHnEFe1RDV9eMVIUyabtfI/wx12k8vOHQfqnO3i7YUj5n/Ujj/X7xVWGv1d QMFRoF32VIQuMlpdW4QAPBopUQ/8L/Bwtdb2mBorHmKPzdgY6QReyZqGhQeRd9GctZCxiTXC mOIJ5G67z0tdwwMbpELuKaNeuBnI9GKc6mVm7Nqzssw24yoT0Z1amBDYdEs2+g==
Message-ID: <1f54ada2-c0e2-2664-1137-b3382fa7a605@nccgroup.trust>
Date: Thu, 12 Jul 2018 14:56:22 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Language: en-US
X-Originating-IP: [10.1.120.175]
X-ClientProxiedBy: MANCASEXCH01.nccgroup.local (10.1.120.101) To MANDBSEXCH03.nccgroup.local (10.1.120.104)
CAMPAIGN: C_PlainText
SIGNATURE: S_PlainText
DISCLAIMER: D_NoDisclaimer
X-MC-Unique: GpWhQSPbN46hxJH9g-i9Bw-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/btSMeDMwGgqDtcsOEYGjpQ0y0Ns>
X-Mailman-Approved-At: Fri, 13 Jul 2018 02:01:03 -0700
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 18:57:49 -0000

Hi QUIC WG.

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