Re: On the relation between QUIC documents

[Mirja Kühlewind <[e-mail]>]

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.

Mirja



> Am 12.07.2018 um 20:56 schrieb Mathias Hall-Andersen <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
>