Draft: draft-ietf-quic-tls

Commentary: This clarifies the TLS interface by explaining that TLS only generates outputs ( handshake bytes or keying material ) in response to inputs . Previously , the only inputs we acknowledged were the handshake bytes , but this recognizes two more : the signal from the client to start handshaking , and - for async validation - a signal that a certificate is OK or not . 
 Were n't we going to say that the traffic keys might get generated asynchronously in ? I wonder how this PR interacts with . I see this PR calling out three types of events ( i.e. generation of CH , input of handshake bytes , completion of certificate validation ) as the " inputs , " then claim that TLS provides the keys " synchronously " in relation to such events . That works as a definition , but I am not sure if it is easy to comprehend . I think my preference would be to talk about ( a)synchronicity from the viewpoint of a transport . It would be easier to say that TLS might provide keys " asynchronously " from what the transport provides as input , then point out that key generation ( possibly in relation to certificate verification ) might take some time . 
 To answer both questions , I am planning on integrating the text from as well . That would cover the case where the TLS stack has to disappear for some time before it produces new outputs , however that manifests . 
 I 've rebased this based on the changes in . Would you mind checking my work ? 
 The label should be instead of . 
 Thanks fixed . 
 The process for interacting with TLS does not acknowledge the possibility that progress in the handshake might depend on inputs other than CRYPTO frames . In particular , endpoints might need to perform additional checking to decide that the TLS handshake is complete . The most important example being the processing that occurs for certificate validation . This is often an asynchronous process , with OCSP and other muck , so recognizing that explicitly in the draft is worthwhile . This might help tease out one of the causes of the problem discussed in , but it does n't lead to a solution . 
 Q : Does this indicate that the TLS changes involved in may be editorial ? I 'd like to focus on the transport and recovery changes to deal with the issue , and it 'd be nice if the tls changes were separate from my perspective . 
 Why is n't adequate for this ? Specifically , is n't it enough to change the stance from synchronous to asynchronous ? 
 I would prefer to explain how certificate validation can take time and block availability of keys . 
 Should this become proposal - ready ? 
 : This is an editorial issue , so no . 
 Thanks looks great !
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.