Hi David, I want to support dropping support of plaintext acks in a bis document.
My focus with developing DTLS 1.3 is using DTLS-SRTP with a hybrid key exchange. We do not have a ressource constrained environment to worry about. So the initial implementation I do for OpenSSL is seeking to minimize complexity. In fact with my current understanding, and with the one application in mind that I'm developing, I actually only need ACKs for the second bullet point of rfc 9147: > 7.3. Design Rationale > ACK messages are used in two circumstances, namely: > * On sign of disruption, or lack of progress; and > * To indicate complete receipt of the last flight in a handshake. I’m not saying that the "network use optimizations” should be dropped completely from the specification. But they do make the specification more complex. And I think some of the complexity comes from the fact that the specification allows ACKs of partial messages. The rest of the complexity comes from acknowledging records that would otherwise eventually be implicitly acknowledged. IMO only fully received messages should be acknowledged. First of all because OpenSSL stores messages to retransmit and not individual records. Second, if the MTU changes while some records have not been acked, then I would expect the implementation to retransmit the records using the new MTU. And then the implementation becomes a bit more complex. With the current specification the implementation is not disallowed to retransmit the full message eventhough some of the records from the previous transmission has been acknowledged (because ACKs can get lost too). Since you are concerned with the interoperability different implementations you should also be aware that Mozilla and WolfSSL have an implementation of DTLS 1.3. So maybe you should reach out to them to get their views before proceeding with the new document. See their comments in the OpenSSL Github issue for DTLS 1.3: I think this is a good start for a discussion, but maybe there exists Below goes my thoughts to your original post. In which I agree that plaintext ACKs should be removed from the specification. > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all) implementation > receives an ACK record for whatever reason, what happens? This decision we > don't get to change. Rather, it is a design constraint. Both OpenSSL and > BoringSSL treat unexpected record types as a fatal error. I haven't checked > other implementations. So I think we must take as a constraint that you > cannot send an ACK unless you know the peer is 1.3-capable. Isn’t this effectively a non-issue? a) A non DTLS 1.3 capable client communicating with DTLS 1.3 capable server: If the server supports the client protocol it will choose DTLS 1.2 or less and will therefore not send an ACK b) A DTLS 1.3 capable client communicating with non DTLS 1.3 capable server: Server will negotiate an earlier version of DTLS and therefore no acks are sent. > 2. Do plaintext ACKs exist? Or is the plaintext epoch permanently at the > old state machine? Honestly, I wish the answer here was "no". That would > have avoided so many problems, because then epochs never change state > machines. Unfortunately, the RFC does not support this interpretation. > Section 4.1 talks about how to demux a plaintext ACK, and section 6, though > wrong, clearly depicts a plaintext ACK. So instead we get to worry about > the transition within an epoch. Keep in mind that transitions happen at > different times on both sides. Keep in mind that there is a portion of the > plaintext epoch that lasts after version negotiation in HelloRetryRequest > handshakes. I agree that plaintext ACKs should be removed from the RFC. > 3. If a 1.3-capable server receives half of a ClientHello, does it send an > ACK? I believe (1) means the answer must be "no". If you haven't read the > ClientHello, you haven't selected the version, so you don't know if the > client is 1.3-capable or not. If the client is not 1.3-capable, sending an > ACK may be incompatible. In addition this would require the use of plaintext ACKs. So for simplicity this case should not be supported in the RFC either. > 4. Is it possible for a 1.3-capable client to receive an ACK *before* it > receives a ServerHello? If so, how does the client respond? I believe the > answer to this question, if plaintext ACKs exist, is unavoidably "yes". > Suppose the server receives a 1.3 ClientHello and then negotiates DTLS 1.3. > That is a complete flight, so Section 7.1 discourages ACKing explicitly > (you can ACK implicitly), but it *does not forbid* an explicit ACK. An > explicit ACK may be sent if the server cannot generate its responding > flight immediately. That means a server could well send ACK followed by > ServerHello. Now suppose ServerHello is lost but the ACK gets through. Now > the client must decide what it's doing. Rejecting the ACK would result in > connection failure, so we must either drop the ACK on the floor, or process > it. While processing it would be more efficient (you don't need to > retransmit the whole ClientHello), it means the plaintext epoch must > support this hybrid state where 1.3 ACKs are processed but never sent! Or > perhaps receiving that ACK transitions you to the 1.3 state machine even > though you don't know the version yet. That all sounds like a mess, so I > would advocate you simply drop it on the floor. Same as above. > 5. If a 1.3-capable client receives half of the server's first message (HRR > or ServerHello), does it send an ACK? Again, because of (1), I believe the > answer must be "no". If you don't know the server's selected version, the > server may not be 1.3-capable and may not be compatible with the ACK. Same as above. > 6. What does a 1.3-capable server do if it receives an ACK prior to picking > the TLS version? Unlike (4), I believe this is impossible. If the client > has something to ACK, the server must have sent something, which the server > will only do once it's received the full ClientHello and thus picked the > version. However, given (4), I suspect an implementation will naturally > just drop that ACK. In this state error vs drop is kinda academic. This is a non-issue.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
