Draft: draft-ietf-quic-tls

Commentary: There were two references , I fixed them both . 
 There is a long development in the section 4 of the TLS draft to explain : I think that this text does not belong in the specification of TLS , which should stick to just explaining how to send the CRYPTO frames . Could it be replaced by a reference to the transport draft ? 
 related to ? 
 Yes it is related , but the specific problem with section 4 is not mentioned in issue 
  . Thanks for cross - linking them . 
 Anyone care to prepare a PR , if we want to make this change ? 
 I did just that -- PR 
 Now that the drafts are not changing as much as they used to , it might be the right time to consider editorial efforts such as revisiting the current split between quic - transport and quic - tls . Let 's imagine that once the RFCs ship , someone wants to build a version of QUIC with a custom handshake / key exchange protocol - they want to deviate as little as possible from QUICv1 , but just want to swap TLS out for something else . Ideally , they would write a new draft that replaces quic - tls , and not change quic - transport at all . And in order to implement this , readers would not need to read quic - tls . More specifically , I think we could accomplish this by moving the following sections from quic - tls to quic - transport : 5 Packet Protection ( except 5.1 Packet Protection Keys ) 6 Key Update ( the interaction with the TLS key schedule would stay in quic - tls but the mechanisms to avoid deadlocks when discarding keys would move to quic - transport ) 7 Security of Initial Messages What do folks think ? I could write up a PR to help make this happen but I 'd like to get a sense of whether there 's interest first . 
 I like this direction . Even if no one ever makes a non - TLS version , I think the document clarity could improve with a change like this . 
 Heavy +1 -- one of the goals of nQUIC [ 1 ] was to exercise the separation between these two drafts . At the time , there was more coupling than desired . Things are in much better shape now . [ 1 ] 
 I 'm supportive of that direction . There was , at one point , an attempt to document the properties that would have to be provided by a generic handshake protocol . The decision to make the transport - spec version - specific and make versions handshake - protocol - specific means we do n't need that text , but an equivalent section noting specifically what features are delegated to and expected of TLS would still be useful . However , I will say that I do n't think this rearrangement needs to or should delay the drafts or WGLC . 
 +1 to this being editorial and not delaying WGLC 
 To clarify , my intention was indeed for this to be editorial and to not have it delay any part of the process whatsoever . 
 Since volunteered to prepare a PR , please let him know when the working copies are stable enough for this shuffling to happen without much pain . 
 It would be nice i the PR also addressed the issue -- section 4 including a long description of which frames belongs in what type of packet , which is better addressed by a reference to the transport draft . 
 my take is that we 're stable enough at this time , if you still have energy to prep a PR . 
 Thanks ! I 'll need a few weeks before I get started on this but I still have the energy . 
 In that case , maybe someone else can get to it sooner - I still have this unfounded optimism that we can be in IETF LC soon ... 
 If there 's a time pressure I can increase the priority of this over other work . Do we have a deadline here ? 
 As you say , WGLC happened . I know that  wants to get some editorial work in after that ( small language fixups , maybe a tiny bit of shuffling of content ) . So this really comes down to one question : When do you want QUIC to be published ? Any time we allow for editorial cleanup adds directly to the time it takes to publish . If WGLC passes this time around with no major issues , then we could immediately publish a -31 draft and make a publication request . Second is the risk that we invalidate the WGLC when we do any significant amount of editorial work . If we plan another round of calls , then this costs little . If we do n't ( see above ) , then this carries some risk of restarting the clock . I guess you could interpret this as " finish this before September 24 or avoid risky changes " . I do n't know how realistic either one is . 
 Looking at what would be entailed , my first instinct was to try slotting it into new subsections of Section 12.1 . However , that makes the TOC deeper than is ideal and would probably require more editorial fine - tuning to get right . If you want to pursue this , I think the fastest path to coherency is to make a new top - level section at the end of the document on Packet Protection and just adjust the cross - references to be forward - references there . Then : New text on the values supplied by TLS ( packet protection keys , header protection keys , ability to generate new keys on demand ) in a subsection of TRANS-7 Move TLS-5.0 into TRANS-(new).0 Retain TLS-5.1 and TLS-5.2 in TLS Split TLS-5.3 , moving the " how to apply selected AEAD and key " into TRANS-(new).1 Move most of TLS-5.4 through TLS-5.6 into subsections of TRANS-(new ) , leaving only the key derivation in TLS TLS-5.7 should mostly move to a subsection of TRANS-13.1 , but some TLS specifics would need to be abstracted out TLS-5.8 should move under TRANS-(new ) TLS-7 should move under TRANS-(new ) , possibly removing specific references to TLS and discussing tampering with the cryptographic handshake generically . TLS-6 is trickier . The mechanics of how to perform a key update on the wire need to move , probably to the final subsection of TRANS-(new ) ; the mechanics of how to obtain the new key need to remain in TLS . These are n't currently clearly separated , and might require some additional text to abstract them . 
 The better is the enemy of the good . I wish we did these changes , because I wish there was no redundancy between the TLS and the transport draft . But then , with the current documents , we did manage to get a large number of implementations that all interoperate . There is a case for leave it as it and ship it now ! 
 Maybe we need a " hold for revision " status for PRs . 
 In any case , I 'd like to second suggestion to get this done by Sep 24 . I know that 's just a few days away , but this seems to be the last issue that requires significant text changes , and so I hope this is doable . 
 OK I 'm starting work on this now . I 'll have a first draft of a PR soon 
 I just pushed PR 4136 ( ) that solves issue 4097 , so you do n't have to do that . 
 I already have that in my PR , so happy to land whichever is ready first and rebase the other . 
 OK I have a first draft at . Reviews welcome ! 
 Thanks for doing the work  . I think that there is a path toward taking that PR , but it 's a long one and the editors feel like it is more important to publish . 
 Thanks Christian , this looks good . I 'll give a chance to review also , but I think it 's worth taking this . Makes sense , thanks for writing this up ,
Paragraph (version B):
Each Handshake layer message (e.g., Handshake, Alerts, and
Application Data) is carried as a series of typed TLS records by the
Record layer.  Records are individually cryptographically protected
and then transmitted over a reliable transport (typically TCP), which
provides sequencing and guaranteed delivery.
Paragraph (version A):
A full 1-RTT handshake in which the client is able to send
Application Data after one round trip and the server immediately
responds after receiving the first handshake message from the
client.
Paragraph (version A):
A 0-RTT handshake in which the client uses information it has
previously learned about the server to send Application Data
immediately.  This Application Data can be replayed by an attacker
so it MUST NOT carry a self-contained trigger for any non-
idempotent action.
Paragraph (version B):
A full 1-RTT handshake, in which the client is able to send
Application Data after one round trip and the server immediately
responds after receiving the first handshake message from the
client.
Paragraph (version B):
Unlike TLS over TCP, QUIC applications that want to send data do not
send it through TLS "application_data" records.  Rather, they send it
as QUIC STREAM frames or other frame types, which are then carried in
QUIC packets.
Paragraph (version A):
One important difference between TLS records (used with TCP) and QUIC
CRYPTO frames is that in QUIC multiple frames may appear in the same
QUIC packet as long as they are associated with the same packet
number space.  For instance, an endpoint can bundle a Handshake
message and an ACK for some Handshake data into the same packet.
Paragraph (version A):
PADDING, PING, and CRYPTO frames MAY appear in any packet number
space.
Paragraph (version A):
CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
0x1c) MAY appear in any packet number space.  CONNECTION_CLOSE
frames signaling application errors (type 0x1d) MUST only appear
in the application data packet number space.
Paragraph (version A):
ACK frames MAY appear in any packet number space, but can only
acknowledge packets which appeared in that packet number space.
However, as noted below, 0-RTT packets cannot contain ACK frames.
Paragraph (version A):
All other frame types MUST only be sent in the application data
packet number space.
Paragraph (version A):
Note that it is not possible to send the following frames in 0-RTT
packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
PATH_RESPONSE, and RETIRE_CONNECTION_ID.  A server MAY treat receipt
of these frames in 0-RTT packets as a connection error of type
PROTOCOL_VIOLATION.
Paragraph (version B):
One important difference between TLS records (used with TCP) and QUIC
CRYPTO frames is that in QUIC multiple frames may appear in the same
QUIC packet as long as they are associated with the same packet
number space.  For instance, an endpoint can bundle a Handshake
message and an ACK for some Handshake data into the same packet.
Some frames are prohibited in different packet number spaces; see
Section 12.5 of QUIC-TRANSPORT.
Paragraph (version A):
If the packet is from a previously installed encryption level, it
MUST NOT contain data which extends past the end of previously
received data in that flow.  Implementations MUST treat any
violations of this requirement as a connection error of type
PROTOCOL_VIOLATION.
Paragraph (version B):
If the packet is from a previously installed encryption level, it
MUST NOT contain data that extends past the end of previously
received data in that flow.  Implementations MUST treat any
violations of this requirement as a connection error of type
PROTOCOL_VIOLATION.
Paragraph (version B):
As keys at a given encryption level become available to TLS, TLS
indicates to QUIC that reading or writing keys at that encryption
level are available.
Paragraph (version B):
The availability of new keys is always a result of providing inputs
to TLS.  TLS only provides new keys after being initialized (by a
client) or when provided with new handshake data.
Paragraph (version B):
However, a TLS implementation could perform some of its processing
asynchronously.  In particular, the process of validating a
certificate can take some time.  While waiting for TLS processing to
complete, an endpoint SHOULD buffer received packets if they might be
processed using keys that aren't yet available.  These packets can be
processed once keys are provided by TLS.  An endpoint SHOULD continue
to respond to packets that can be processed during this time.
Paragraph (version B):
After processing inputs, TLS might produce handshake bytes, keys for
new encryption levels, or both.
Paragraph (version B):
These values are based on the values that TLS negotiates and are used
by QUIC to generate packet and header protection keys; see packet-
protection and header-protect.
Paragraph (version B):
As with TLS over TCP, QUIC protects packets with keys derived from
the TLS handshake, using the AEAD algorithm AEAD negotiated by TLS.
Paragraph (version B):
Version Negotiation packets have no cryptographic protection.
Paragraph (version B):
Retry packets use AEAD_AES_128_GCM to provide protection against
accidental modification or insertion by off-path adversaries; see
retry-integrity.
Paragraph (version B):
Initial packets use AEAD_AES_128_GCM with keys derived from the
Destination Connection ID field of the first Initial packet sent
by the client; see initial-secrets.
Paragraph (version B):
All other packets have strong cryptographic protections for
confidentiality and integrity, using keys and algorithms
negotiated by TLS.
Paragraph (version B):
This section describes how packet protection is applied to Handshake
packets, 0-RTT packets, and 1-RTT packets.  The same packet
protection process is applied to Initial packets.  However, as it is
trivial to determine the keys used for Initial packets, these packets
are not considered to have confidentiality or integrity protection.
Retry packets use a fixed key and so similarly lack confidentiality
and integrity protection.
Paragraph (version B):
The current encryption level secret and the label "quic key" are
input to the KDF to produce the AEAD key; the label "quic iv" is used
to derive the Initialization Vector (IV); see aead.  The header
protection key uses the "quic hp" label; see header-protect.  Using
these labels provides key separation between QUIC and TLS; see key-
diversity.
Paragraph (version B):
The KDF used for initial secrets is always the HKDF-Expand-Label
function from TLS 1.3; see initial-secrets.
Paragraph (version B):
Initial packets apply the packet protection process, but use a secret
derived from the Destination Connection ID field from the client's
first Initial packet.
Paragraph (version B):
Future versions of QUIC SHOULD generate a new salt value, thus
ensuring that the keys are different for each version of QUIC.  This
prevents a middlebox that recognizes only one version of QUIC from
seeing or modifying the contents of packets from future versions.
Paragraph (version B):
The secrets used for constructing Initial packets change when a
server sends a Retry packet to use the connection ID value selected
by the server.  The secrets do not change when a client changes the
Destination Connection ID it uses in response to an Initial packet
from the server.
Paragraph (version B):
test-vectors contains sample Initial packets.
Paragraph (version B):
When constructing packets, the AEAD function is applied prior to
applying header protection; see header-protect.  The unprotected
packet header is part of the associated data (A).  When processing
packets, an endpoint first removes the header protection.
Paragraph (version B):
The output of this algorithm is a 5-byte mask that is applied to the
protected header fields using exclusive OR.  The least significant
bits of the first byte of the packet are masked by the least
significant bits of the first mask byte, and the packet number is
masked with the remaining bytes.  Any unused bytes of mask that might
result from a shorter packet number encoding are unused.
Paragraph (version B):
The client has not demonstrated liveness, unless the server has
validated the client's address with a Retry packet or other means;
see Section 8.1 of QUIC-TRANSPORT.
Paragraph (version B):
Therefore, the server's use of 1-RTT keys before the handshake is
complete is limited to sending data.  A server MUST NOT process
incoming 1-RTT protected packets before the TLS handshake is
complete.  Because sending acknowledgments indicates that all frames
in a packet have been processed, a server cannot send acknowledgments
for 1-RTT packets until the TLS handshake is complete.  Received
packets protected with 1-RTT keys MAY be stored and later decrypted
and used once the handshake is complete.
Paragraph (version B):
A client generally receives 1-RTT keys at the same time as the
handshake completes.  Even if it has 1-RTT secrets, a client MUST NOT
process incoming 1-RTT protected packets before the TLS handshake is
complete.
Paragraph (version B):
An endpoint MUST retain old keys until it has successfully
unprotected a packet sent using the new keys.  An endpoint SHOULD
retain old keys for some time after unprotecting a packet sent using
the new keys.  Discarding old keys too early can cause delayed
packets to be discarded.  Discarding packets will be interpreted as
packet loss by the peer and could adversely affect performance.
Paragraph (version B):
An endpoint SHOULD retain old read keys for no more than three times
the PTO after having received a packet protected using the new keys.
After this period, old read keys and their corresponding secrets
SHOULD be discarded.
Paragraph (version A):
For example, an attacker could inject a packet containing an ACK
frame that makes it appear that a packet had not been received or to
create a false impression of the state of the connection (e.g., by
modifying the ACK Delay).  Note that such a packet could cause a
legitimate packet to be dropped as a duplicate.  Implementations
SHOULD use caution in relying on any data which is contained in
Initial packets that is not otherwise authenticated.
Paragraph (version B):
For example, an attacker could inject a packet containing an ACK
frame that makes it appear that a packet had not been received or to
create a false impression of the state of the connection (e.g., by
modifying the ACK Delay).  Note that such a packet could cause a
legitimate packet to be dropped as a duplicate.  Implementations
SHOULD use caution in relying on any data that is contained in
Initial packets that is not otherwise authenticated.
Paragraph (version B):
An attacker could guess values for packet numbers or Key Phase and
have an endpoint confirm guesses through timing side channels.
Similarly, guesses for the packet number length can be tried and
exposed.  If the recipient of a packet discards packets with
duplicate packet numbers without attempting to remove packet
protection they could reveal through timing side-channels that the
packet number matches a received packet.  For authentication to be
free from side-channels, the entire process of header protection
removal, packet number recovery, and packet protection removal MUST
be applied together without timing and other side-channels.