On Thu, Sep 19, 2024 at 1:31 PM David Benjamin <david...@google.com> wrote:
> Ah fun, another issue in this document. So not only are write epoch > lifetimes unspecified and complex with 0-RTT, but read epoch lifetimes > *are* specified but *wrong*. > > Section 4.2.1 says: > > > Because DTLS records could be reordered, a record from epoch M may be > received after epoch N (where N > M) has begun. Implementations SHOULD > discard records from earlier epochs but MAY choose to retain keying > material from previous epochs for up to the default MSL specified for TCP > [RFC0793] to allow for packet reordering. (Note that the intention here is > that implementers use the current guidance from the IETF for MSL, as > specified in [RFC0793] or successors, not that they attempt to interrogate > the MSL that the system TCP stack is using.) > > https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1 > > First, it's a bit weird to say you SHOULD discard *records* but MAY > retain *keying material*. I assume that meant SHOULD discard records but > MAY process records anyway up to MSL. Anyway, this model implies that only > one read epoch is active at once, but this isn't true. You basically have > to read epoch 1 (early data) as unordered relative to epoches 0 and 2. > Consider a DTLS 1.3 server: > > 1. The server reads ClientHello with early_data extension at epoch 0 and > accepts early data. > 2. The server sends ServerHello (epoch 0), EE..Finished (epoch 2), and > activates write epoch 3 for half-RTT application data. > 3. The server reads early data (epoch 1) from the client. The RFC would > lead you to think the server can close read epoch 0 now, but... > 4. ServerHello gets lost and, if we are to believe > https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8, the client > might send an empty plaintext ACK to trigger a retransmit. This ACK will be > at epoch 0. This only works if the server keeps read epoch 0 open! > 5. Client eventually gets the ServerHello but now it only gets half of the > epoch 2 data. It sends an ACK to trigger another retransmit. This ACK will > come at epoch 2. > 6. Server receives that ACK at epoch 2 and retransmits. The RFC would lead > you to think the server can close read epoch 1 now, but... > 7. Let's say that retransmit is lost again, or hasn't arrived yet. From > the client's perspective, it has a connection that has yet to reach the > 1-RTT point, so any data from the calling application will still be sent as > early data. That means the client will continue to send early data at epoch > 1. This only works if the server keeps read epoch 1 open! > 8. The handshake progresses and the server finally gets 1-RTT data at > epoch 3 from the client. *Now* the spirit of the rule in the text applies > to epoch 1 and the server can close the epoch (after optionally waiting a > spell for reordering) > Ah right, Nick Harper points out that servers really should close read epoch 1 [up to a delay to accommodate reordering] as soon as they receive the Finished message (epoch 2) and complete the handshake, not wait for an epoch 3 record. (But it must specifically be on handshake completion, not *any* epoch 2 record. Record-layer only logic cannot assume 1 < 2 because 2 might contain pre-Finished ACKs.) All this is missing from the specification. :-) I think we need to rewrite the spec text on epochs to more explicitly discuss their lifetimes. > So the rule is actually that we close according to a partially ordered set: > - 0 (unencrypted) < 2 (handshake) < 3 (first app data) < 4 < 5 < ... > - 1 (early data) < 3 (first app data) < 4 < 5 < ... > - 1 is not ordered relative to 0 and 2. > > > On Wed, Sep 18, 2024 at 3:47 PM David Benjamin <david...@google.com> > wrote: > >> One more wriggle if we wish to allow unencrypted ACKs, though it is >> fixable. Section 7, says: >> >> > During the handshake, ACK records MUST be sent with an epoch which is >> equal to or higher than the record which is being acknowledged. [...] >> Implementations SHOULD simply use the highest current sending epoch, which >> will generally be the highest available. After the handshake, >> implementations MUST use the highest available sending epoch. >> >> Taken at face value, that text implies that a client sending 0-RTT data >> should send its ACKs at the highest current sending epoch, epoch 1 (0-RTT). >> But if the server has rejected 0-RTT data, it will not (and cannot) >> instantiate epoch 1 at all, so it won't get the ACKs! That guidance needs a >> special case: if you would have ACKed at epoch 1, you should ACK at epoch 0 >> instead. >> >> Alternatively, one might interpret that situation as 0 being the sending >> epoch and 1 being some magical epoch on the side. This isn't supported by >> the document, but honestly no interpretation is supported by the document >> because the document never tells you what a "current sending epoch" even >> is. While 4.2.1 gives some rough guidance on when to close out receiving >> epochs, I could not find any text on send epoch management at all. >> Reasoning through the protocol, you might arrive at this *almost* correct >> rule: >> >> A write epoch may be discarded IF: >> 1. It is not the highest available epoch. AND >> 2. There are no unacked, outgoing messages at that epoch >> >> That rule, however, does not work in 0-RTT. If the highest epoch is 1, >> you cannot discard 0. The server might reject 0-RTT and then send >> HelloRetryRequest, at which point you will need to discard epoch 1 and >> reactivate epoch 0, maintaining continuity of sequence numbers. The >> 0-RTT/1-RTT transition is also interesting on the write side, though I'll >> start a separate thread for that. >> >> All this is subtle enough that it should not be left as an exercise to >> the reader. >> >> David >> >> On Wed, Sep 18, 2024 at 12:39 AM Bob Beck <b...@obtuse.com> wrote: >> >>> >>> >>> > On Sep 17, 2024, at 5:28 PM, David Benjamin <davidben= >>> 40google....@dmarc.ietf.org> wrote: >>> > >>> > Ah, I just noticed this text at the end of Section 7.1: >>> > >>> > > Note that in some cases it may be necessary to send an ACK which >>> does not contain any record numbers. For instance, a client might receive >>> an EncryptedExtensions message prior to receiving a ServerHello. Because it >>> cannot decrypt the EncryptedExtensions, it cannot safely acknowledge it (as >>> it might be damaged). If the client does not send an ACK, the server will >>> eventually retransmit its first flight, but this might take far longer than >>> the actual round trip time between client and server. Having the client >>> send an empty ACK shortcuts this process. >>> > >>> > https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8 >>> > >>> > I guess then the intent is indeed that if you receive some random >>> encrypted DTLS 1.3 header, even though you don't know it's DTLS 1.3 yet, >>> you interpret as activating the ACKing mechanism? But that seems to prompt >>> more questions than it answers. For instance, what happens if you do that, >>> but then finally receive the ServerHello and it turns out this was just >>> some junk packet and we're really negotiation DTLS 1.2? Do you check that >>> the ACK mechanism has been activated and return an error? Do you just pause >>> the ACK mechanism and hope you're in an OK state? This seems quite prune to >>> send the implementation into unexpected and untested states. >>> > >>> > >>> >>> >>> Yeah, I think this has missed a nasty corner case here for >>> implementations that support both. >>> >>> I think I also lean towards option A) (from below) here. Anyone else who >>> has gotten at least their hands mildly dirty in a DTLS implementation that >>> supports both 1.2 and 1.3 care to chime in as well? >>> >>> >>> > On Thu, Sep 12, 2024 at 4:31 PM David Benjamin <david...@google.com> >>> wrote: >>> > Hi all, >>> > >>> > I noticed another issue with the DTLS 1.3 ACK design. :-) >>> > >>> > So, DTLS 1.3 uses ACKs. DTLS 1.2 does not use ACKs. But you only learn >>> what version you're speaking partway through the lifetime of the >>> connection, so there are some interesting corner cases to answer. As an >>> illustrative example, I believe the diagram in section 6 is [probably] >>> incorrect: >>> > https://www.rfc-editor.org/rfc/rfc9147.html#section-6 >>> > >>> > If the client loses the first packet, it never sees the ServerHello >>> and thus learns it's speaking DTLS 1.3. While it does see the second >>> packet, that packet only contains ciphertext that it cannot decrypt. Unless >>> it decides to say "this looks like a 1.3 record header, therefore I will >>> turn on the 1.3 state machine", which isn't supported by the RFC (maybe TLS >>> 1.4 will use the same record header but redo ACKs once again), it shouldn't >>> activate the 1.3 state machine yet. I expect what will actually happen is >>> that the client will wait for the retransmission timeout a la DTLS 1.2. >>> > >>> > More generally, I believe these are the situations to worry about: >>> > >>> > 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. >>> > >>> > 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. >>> > >>> > 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. >>> > >>> > 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. >>> > >>> > 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. >>> > >>> > 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. >>> > >>> > From what I can tell, RFC 9147 is silent on all of this. I think it >>> should say something. I believe these are the plausible options: >>> > >>> > OPTION A -- There are no ACKs in epoch 0. >>> > >>> > We avoid this ridiculous transition point and say that ACKs only exist >>> starting epoch 1. Epoch 0 uses the old DTLS 1.2 state machine. This is very >>> attractive from a simplicity perspective, but since RFC 9147 was already >>> published with this ambiguity, I think we need to, at minimum, say that >>> DTLS 1.3 implementations drop epoch 0 ACKs on the floor. It also means that >>> packet loss in HelloRetryRequest flows may be less efficient. That said, if >>> your HelloRetryRequest is stateless (not applicable to all DTLS uses), >>> you're probably not doing anything with ACKs anyway. Saying those ACKs >>> avoids having to think about that case, at the cost of a worse transport >>> for stateful HelloRetryRequest. >>> > >>> > OPTION B -- Epoch 0 enables ACKing once the version is learned. >>> > >>> > Once you know the version, you start sending and processing ACKs. >>> Before you know the version, you drop ACKs on the floor and never send >>> them. This requires convincing ourselves that the transition point works >>> out, notably when one side is still ACK-less and the other side is still >>> ACK-ful, but I believe it works out. >>> > >>> > OPTION C -- Epoch 0 always receives and acts on ACKs, but it doesn't >>> send ACKs until the version is learned. >>> > >>> > This is the same as above, but instead of dropping ACKs, you go ahead >>> and let that drive your state machine. But you don't send them. This makes >>> reasoning about the protocol even more complicated because there are even >>> more states you can be in w.r.t. your known version vs the state of your >>> transport. It does improve behavior around packet loss, but I think it only >>> helps this edge case in question (4) above, which is already a case where >>> servers aren't expected to send ACKs anyway. >>> > >>> > I think I lean towards Option A for simplicity, even though it >>> decidedly contradicts a lot of text in the RFC right now. That will be hard >>> to encode in an erratum as a few things need to change. But I also have 7 >>> other eratta open against this document, so maybe it's time for rfc9147bis. >>> > >>> > David >>> > _______________________________________________ >>> > TLS mailing list -- tls@ietf.org >>> > To unsubscribe send an email to tls-le...@ietf.org >>> >>>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
