Draft: draft-ietf-quic-transport

Commentary: We do n't ever really say that QUIC depends on TLS providing the properties that we claim TLS provides . So it 's worth pointing that exposure . This is more so because some of the properties we claim are dependent on these properties . 
 ( Cleaned up duplicate instances of the same comment . ) 
 As per comment I 'll note that there is MITM protection in QUIC , but it is not immediate which is roughly why we have the concept of handshake confirmed . 
 The options for triage are close it , mark as editorial , or mark as design . This has a needs - discussion , and I 'm seeing a lack of any discussion . So you might see where my thought process is going ... this relates to your PR on the QUIC threat model . Are you willing to provide some comment that helps us triage the issue ? 
 I think that we can take this as editorial , as it merely requires that we capture already agreed principles ( we do n't protect against an adversary who can inject packets ) . assistance would be useful , but I can produce text if nothing is forthcoming . 
 I can always provide comments , no guarantees on how much they 'll help triage IIRC , this is an issue filed from a comment on the threat model PR that was several - months merged to potentially increase the scope of what that covered . I think that the original threat model that and I put together , covering the handshake and migration respectively , is intended to be the start of that section -- as additional items are discovered that could use coverage there to help clarify QUIC 's stance on whatever issue , they should totally be . I agree with that adding such items seem editorial , as they are n't introducing any new requirements and are only capturing current realities as specified elsewhere . ( Of course , as that text is written , it seems logical that putting it all in words next to each other may highlight issues , and if the WG decides that we do n't like how the current spec results in a particular security stance , we can open a design issue to change normative text elsewhere . ) So , I 'd probably consider this editorial , and ask to potentially contribute some text or clarify what he 's looking to have covered by the original comment -- once that 's clear , happy to help get a PR up if needed ( or text is always good too ! ) . 
 Since this concerns the handshake , I 'm not too confident in contributing text but I 'd be happy to review and discuss . I believe it is correct that the issue is covered in existing text elsewhere but as says , it makes sense to cover it in one place . The risk is that the reader is not aware how important it is to reach a certain point in the connection before trusting data , and especially to those seeking to create derived versions . From various discussions I 'm not sure the importance is broadly understood . Additionally , I 'm not entirely convinced that the current text fully captures the problem - not that we necessarily can - for example various stateless transmissions / redirects / token issues - might assume a level of privacy that does n't exist in all cases , thus requiring stronger integrity elsewhere such as in CIDs , tokens etc .. 
 Thanks folks . It seems we have a path forward , so I 'm removing the needs - discussion label . The editorial process will naturally generate some back and forth but that is the same for all editorial issues .
Paragraph (version A):
The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
cryptographic properties described in Appendix E.1 of TLS13.
Paragraph (version A):
In addition to those properties, the handshake is intended to provide
some defense against DoS attacks on the handshake, as described
below.
Paragraph (version B):
The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
cryptographic properties described in Appendix E.1 of TLS13.  Many of
the security properties of QUIC depend on the TLS handshake providing
these properties.  Any attack on the TLS handshake could affect QUIC.
Paragraph (version B):
Any attack on the TLS handshake that compromises the secrecy or
uniqueness of session keys affects other security guarantees provided
by QUIC that depends on these keys.  For instance, migration
(migration) depends on the efficacy of confidentiality protections,
both for the negotiation of keys using the TLS handshake and for QUIC
packet protection, to avoid linkability across network paths.
Paragraph (version B):
An attack on the integrity of the TLS handshake might allow an
attacker to affect the selection of application protocol or QUIC
version.
Paragraph (version B):
In addition to the properties provided by TLS, the QUIC handshake
provides some defense against DoS attacks on the handshake.
Paragraph (version A):
The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key
exchange.  Further, parameter negotiation is folded into the TLS
transcript and thus provides the same security guarantees as ordinary
TLS negotiation.  Thus, an attacker can observe the client's
transport parameters (as long as it knows the version-specific salt)
but cannot observe the server's transport parameters and cannot
influence parameter negotiation.
Paragraph (version B):
The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key
exchange.  Further, parameter negotiation is folded into the TLS
transcript and thus provides the same integrity guarantees as
ordinary TLS negotiation.  An attacker can observe the client's
transport parameters (as long as it knows the version-specific keys)
but cannot observe the server's transport parameters and cannot
influence parameter negotiation.