On the relation between QUIC documents

[Mathias Hall-Andersen <[e-mail]>]

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