Implicit acknowledgment during handshake

[ekr]

The motivation for this issue is: What happens if you receive a ServerCleartext packet that contains SH but doesn't contain the acknowledgement for CI? Should you eventually retransmit CI? This doesn't make sense, but the protocol suggests you should.

We could just make it an exception, but I think we might want to go bigger. Specifically, I propose we take the data in ClientInitial out of stream 0 and make it special data. It is anyway because it can't be fragmented, has to be padded, etc. Then the client's second flight would go in stream 0 at offset 0.

[mikkelfj]

Related question - why does the client send end of handshake in a cleartext packets after receiving server handshake, except for retransmission of earlier packets no longer needed.

QUIC TLS draft section 4.1:

@C QUIC STREAM Frame(s) <0>:
(EndOfEarlyData)
{Finished}

[ekr]

It avoids double-encryption of the TLS handshake packets.

[mikkelfj]

It avoids double-encryption of the TLS handshake packets.

I may get the following wrong, as I haven't studied everything in detail yet, but my take is, ignoring 0RTT:

If the server was required to only respond with a single packet, and double encryption was acceptible (which I think is no problem at all), then the handshake could have the form:

@c ClientInitial ->
<-c ServerInitial
@1 stream 0{EndOfEarlyData, Finished}, Optionally other streams ->

No ACKS in server to client, no acks in client to server.

If these initial packets are made special, as you suggest with ClientInitial, we can also drop packet numbering of these.

This also avoids the issue with ACKS of untrusted packets during handshake: #624

[mikkelfj]

In addition, I suggest that ServerInitial sends (reflects) the Client Connection ID (CCID) and ALSO sends a new Server Connection ID (SCID). This uniquely links the client request to the server response, and also handles Stateless Retry and Version Negotiation packet responses if these do the same thing, mirroring CCID except these other packets won't have a SCID. In addition, this would avoid having to rely on the uniqueness of a 5-tuple for setting up and maintaining connection state.

[ekr]

"If the server was required to only respond with a single packet..."

This is not a reasonable assumption. Certificates regularly push you over the MTU.

[mikkelfj]

This is not a reasonable assumption. Certificates regularly push you over the MTU.

Could this not also happen to client certificates when server requires auth?

Could certs be seperate from Diffie-Hellman?

[ekr]

Could this not also happen to client certificates when server requires auth?

Yes.

Could certs be seperate from Diffie-Hellman?

They are. Client certificates are sent in the second flight.

[mikkelfj]

They are. Client certificates are sent in the second flight.

So in principle this could also apply to server certs, and then you could have fully protected packets except for the initial key exchange.

[mikkelfj]

It would also deal with #597,#608 - especially if CCID is reflected, and paired with SCID when available, on all unprotected server sent packets.

[ekr]

This would add a new type of complexity because the keys that are available after the initial key exchange are not the same as those which are available after the handshake completes.

[mikkelfj]

Is that necessarily so, given stateless retry? And key phase must be handled anyway. I don't want to add complexity though.

[ekr]

On Tue, Jun 13, 2017 at 12:56 PM, MikkelFJ ***@***.***> wrote: Is that necessarily so, given stateless retry?

It's a property of the TLS handshake. And key phase must be handled anyway.

Well, it's also complexity at the TLS layer: we don't even export that key

…

I don't want to add complexity though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#627 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1ob8O8-In2lq9FB8GGgFj6vOxo1Kpks5sDnkJgaJpZM4N4JZC> .

[martinthomson]

Editors discussed this, and for both Handshake and Retry from the server, we will mandate the inclusion of ACK. This allows clients to drive loss detection based purely on ACK logic. However, we will encourage clients not to send more Initial packets if they get packets from the server. This might be happen if they receive packets out of order or the packet with ACK is lost. The client can then ACK rather than retransmitting the Initial.

Note that this creates a situation that makes no sense. If the client receives an out-of-order packet from the server, it will assume that the Initial was lost and might reasonable send a Handshake containing an ACK and the ClientHello. We need to separately disable sending Initial if packets are received (and only re-enable it if the packet was VN/Retry - both of those cause a new Initial packet to be created).

[martinthomson]

Note that the issue OP makes a proposal. I think that we're in the process of discussing that particular issue, but we need a little more clarity on that problem. When that discussion matures some more, we can open an issue for stream 0 usage and offsets, etc...