Re: [quicwg/base-drafts] Improve KEY_PHASE description (#43)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +* A server MUST NOT retransmit any of its TLS handshake messages with 1-RTT
+  keys.  The client needs these messages in order to determine the 1-RTT keys.
+
+A HelloRetryRequest might be used to reject an initial ClientHello.  A
+HelloRetryRequest handshake message and any second ClientHello that is sent in
+response MUST also be sent without packet protection.  This is natural, because
+no new keying material will be available when these messages need to be sent.
+
+Note:
+
+: An alternative way of identifying handshake data that needs to be sent without
+  protection is to collect all handshake data from before TLS provides the first
+  keys (see {{key-ready-events}}).
+
+Retransmissions of these handshake messages MUST be send in unprotected packets
+(with a KEY_PHASE of 0).  Any ACK frames for these messages MUST also be send in

The problem we have is that an ACK might not be readable if it is encrypted.  See #34.

1. If the server ACKs the ClientHello by encrypting it, that's probably OK, it has to do that with 1-RTT keys.  But the client might not have the 1-RTT keys because it needs the entire set of server handshake messages to that.

2. If the client ACKs the ServerHello (et al.) with 0-RTT keys, then those ACKs are lost if the server rejects 0-RTT.  I guess you could say that this is OK on the basis that we lose ACKs too, but I think that it could force the server into retransmission on a timer (ugh).

3. If the client ACKs the ServerHello (et al.) with 1-RTT keys, then the server should be able to decrypt them perfectly well.  However, the only value gained from this is better feedback on timing, it doesn't help with loss recovery because there was none.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/43