[TLS] [Technical Errata Reported] RFC9147 (8108)
The following errata report has been submitted for RFC9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8108 -- Type: Technical Reported by: David Benjamin Section: 7.2 Original Text - acknowledgements for records which have already been ACKed. As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight to which it is responding. Corrected Text -- acknowledgements for records which have already been ACKed. As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight to which it is responding. If any element of record_numbers in the ACK references an epoch that is higher than the epoch in which the ACK was received, the implementation MUST terminate the connection with an "illegal_parameter" alert. Notes - Section 7 discusses that you cannot send ACKs for later epochs, but does not say anything about what the receiver does. To prevent an attacker from, e.g., using a plaintext ACK to interfere with ACKs of an encrypted epoch, I think we need to tell the receiver to check this. Otherwise we need to be much more explicit about the points at which the receiver MUST close old epochs. Honestly, we probably should be explicit about this too, but we should also be clear on this point. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC9147 (draft-ietf-tls-dtls13-43) -- Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Publication Date: April 2022 Author(s) : E. Rescorla, H. Tschofenig, N. Modadugu Category: PROPOSED STANDARD Source : Transport Layer Security Stream : IETF Verifying Party : IESG ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] DTLS 1.3 and the 0-RTT <-> 1-RTT transition
Another issue with RFC 9147: when does the client switch from sending 0-RTT to 1-RTT app data, and when does the server start processing 1-RTT app data from the client? This is less of an open question (I think we match how we already resolved this for QUIC), but is something we should have written down, so consider this yet another reason we need rfc9147bis. Presumably, the client starts sending 1-RTT data, and stops sending 0-RTT data, as soon as it has sent out its Finished message. This matches other handshake flows, and also avoids the calling application getting confused about continuing to send early data after the handshake is reported as completed. But then that begs the opposite question: does the server install the 1-RTT read keys before or after it receives client Finished? If before, it's honestly fine (the AEAD tag does the same thing), but it breaks assumptions made in TLS analysis. If after, there is an awkward hiccup in the server's ability to receive data from the client, if the Finished packet is lost. For QUIC, we ended up deciding: - You do not decrypt 1-RTT records until you've received/sent enough to finish the handshake. - There is a head-of-line blocking problem at the transition point. - Clients can mitigate this by eagerly packing the Finished with their app data until they get an ACK. https://www.rfc-editor.org/rfc/rfc9001.html#section-5.7 TBH, I doubt anyone will actually do the last one. (We are not currently planning to implement 0-RTT for DTLS at all, unless it ends up being an easy extra thing.) But I think this is worth writing down explicitly. The exact timings of key transitions are much more visible to DTLS and QUIC than they are to TLS, so I think this is worth being explicit about. David ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: DTLS 1.3 ACKs near the version transition
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 wrote: > > > > On Sep 17, 2024, at 5:28 PM, David Benjamin 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 > 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
[TLS] [Technical Errata Reported] RFC9147 (8107)
The following errata report has been submitted for RFC9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8107 -- Type: Technical Reported by: David Benjamin Section: 7 Original Text - During the handshake, ACK records MUST be sent with an epoch which is equal to or higher than the record which is being acknowledged. Note that some care is required when processing flights spanning multiple epochs. For instance, if the client receives only the ServerHello and Certificate and wishes to ACK them in a single record, it must do so in epoch 2, as it is required to use an epoch greater than or equal to 2 and cannot yet send with any greater epoch. 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. Corrected Text -- During the handshake, ACK records MUST be sent with an epoch which is equal to or higher than the record which is being acknowledged. Note that some care is required when processing flights spanning multiple epochs. For instance, if the client receives only the ServerHello and Certificate and wishes to ACK them in a single record, it must do so in epoch 2, as it is required to use an epoch greater than or equal to 2 and cannot yet send with any greater epoch. Implementations SHOULD simply use the highest current sending epoch, which will generally be the highest available. The exception is that implementations MUST NOT send ACK records in epoch 1 (early data). If the highest current sending epoch is epoch 1 (early data), implementations MUST use epoch 0 (unencrypted) to send ACK records. After the handshake, implementations MUST use the highest available sending epoch. Notes - With the caveat that unencrypted ACKs are generally goofy (see https://mailarchive.ietf.org/arch/msg/tls/ZEj04LyL3hJXeK1nsiOBoB2vCsg/), the document currently believes they exist. As long as they exist, the rule in the text right now does not work. The server may reject 0-RTT, in which case it will never see epoch 1. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC9147 (draft-ietf-tls-dtls13-43) -- Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Publication Date: April 2022 Author(s) : E. Rescorla, H. Tschofenig, N. Modadugu Category: PROPOSED STANDARD Source : Transport Layer Security Stream : IETF Verifying Party : IESG ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
