[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer
Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 05 November 2024 14:15 UTC
Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBB2C1D4A68 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2024 06:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-Zeb5of4Mpn for <tls@ietfa.amsl.com>; Tue, 5 Nov 2024 06:15:43 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D19C1ECA8C for <tls@ietf.org>; Tue, 5 Nov 2024 06:15:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 9718E67AB4 for <tls@ietf.org>; Tue, 5 Nov 2024 16:15:38 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id FcjOwC3RtKfQ for <tls@ietf.org>; Tue, 5 Nov 2024 16:15:38 +0200 (EET)
Received: from LK-Perkele-VII2 (87-92-153-79.rev.dnainternet.fi [87.92.153.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4F5D472 for <tls@ietf.org>; Tue, 5 Nov 2024 16:15:37 +0200 (EET)
Date: Tue, 05 Nov 2024 16:15:36 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <ZyooiLIxka6ZQc_x@LK-Perkele-VII2.locald>
References: <CAF8qwaCKtjis=h6npApRAtT=AbHtDHO333zAXKPMowH_V5K8NQ@mail.gmail.com> <ZyeaTZctp5mX-ck3@LK-Perkele-VII2.locald> <CAF8qwaDkEbwFHd7teVY4c-EZ7JO5eBigehUEF21ZA3VPRbwJNQ@mail.gmail.com> <ZykCAFMIEHhZRNZg@LK-Perkele-VII2.locald> <CAF8qwaB7pSUpNS5Y5U53Yx69_1V24rq-FJbXyV7yNYi-7UDTmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAF8qwaB7pSUpNS5Y5U53Yx69_1V24rq-FJbXyV7yNYi-7UDTmg@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: M4OMRMHF4GZBXQWQRECTPQC4AT4UAUQR
X-Message-ID-Hash: M4OMRMHF4GZBXQWQRECTPQC4AT4UAUQR
X-MailFrom: ilariliusvaara@welho.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Gfs1NXfhLTUYQXvn22dBa-UdWT4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
On Tue, Nov 05, 2024 at 11:47:44AM +0000, David Benjamin wrote: > On Mon, Nov 4, 2024 at 5:19 PM Ilari Liusvaara <ilariliusvaara@welho.com> > wrote: > > > > > If the blocking flight has response, then explicit ACK is required to > > avoid deadlock (to get out of state where both sides have flight in > > progress). But this can only happen post-handshake. > > > > Oh I see. The concern is a sender that is only willing to have one outgoing > flight at a time? So if both sides, say, send a post-handshake > CertificateRequest, neither will be willing to move on and send a > responding Certificate until then things have cleared. I agree that this > situation is indeed a problem. > > I'm not sure what's the best way out of that mess. The spec says you > "duplicate" the state machine, whatever that means, but having only one > outgoing flight is indeed a very sensible restriction; it's one I've been > considering for our implementation. The specification is incredibly > ambiguous around how parallel post-handshake transactions work! I still > need to figure out how we want to handle post-handshake messages, but I'd > definitely been considering that restriction. But I also don't intend to > implement any multi-flight post-handshake transactions because, well, we > don't need them but more importantly I cannot make sense of how to make > them work well at all. (See all the threads I've started here.) > > I'm not sure what's the best way out of that mess, but I hope we can spend > time with the badly-needed rfc9147bis to improve this. Another edge case: - Sender sends two parallel flights, the second one prepares epoch change. - Receiver can buffer multiple messages at once. - One of the messages from first flight is lost, the second flight goes all through. - The receiver ACKs everything it got. - The sender thinks second flight is complete, the receiver thinks it is incomplete. - Prepare for epoch change is complete, so sender changes epoch. - Receiver is not ready for epoch change. If the keys for the next epoch depend on the preparing flight, it can not even compute the correct keys. To avoid that problem: - Each epoch can have at most one message that prepares epoch change. - All flights up to one that prepares the epoch change must be completed before the actual epoch change. Currently, the messages that prepare epoch change are Finished (only within handshake), and KeyUpdate. But there could be more in the future. There is WG draft for Extended Key Update. That can be initiated from either side, needs at least three flights (and the current version has four flights) and prepares epcoh changes. Basically hits every edge case there is. > > With regards to state-keeping, i think that it would be enough to > > track the following: > > > > - The first message sequence in the current flight. > > - Current flight complete flag. > > - First message sequence in next flight (if current flight complete). > > > > ... Which fits in 5 bytes (+ padding). > > > > This lets one recognize if record belongs to past (ignore), current > > (process) or next (next becomes current, and process) flight. > > > > Hmm, I'm not sure if that's sufficient. While the sender might choose to > restrict themselves to only one outgoing flight at a time for simplicity, a > receiver can't assume that the sender has done so. The sender might have > decided to send 10 NewSessionTickets in parallel. On the receiver side, you > might receive them, maybe even in order, and then ACK them in sequence. But > perhaps the very first ACK got lost, so the sender retransmits the first > NewSessionTicket. It is expecting you to ACK it again, or it will keep > retransmitting. Oh yeah, it does not work if there can be multiple outstanding flights. > That means that, post-handshake, the receiver needs to ACK messages > basically arbitrarily back. That is fine because you still only need to > track the current sequence number and ACK any past ones without processing > anything. But it means the notion of "current flight" is everlasting. Every > post-handshake transaction leaves its final flight around as the "current > flight". > > But now suppose you want to distinguish "current flight" from "past flight" > and only ACK current flights. *Now* you need per-transaction state to know > which old sequence numbers are from current vs past flights, in every > post-handshake transaction. This seems problematic, so I think we should > make sure the protocol works if you ACK all past sequence numbers > indiscriminately. But if that's simpler, maybe we should just say that's > the ACK policy and stop being fussy about only ACKing one flight at a time. What if the past flight has reply? Unless one has got an (implicit) ACK from the other side about the reply, retransmission on flight signals to retransmit the reply. E.g., server sends CertificateRequest and 9 NSTs in parallel. Client insta-NAKs the CR, and ACKs all the NSTs. The NAK gets lost. Server re-transmits the CR. Now client has to resend the NAK from 9 flights back. Since any such reply must be pending flight, one could track the range of message sequences that trigger retransmit for pending flight. -Ilari
- [TLS] DTLS 1.3 ACK sorting, and when to clear the… David Benjamin
- [TLS] Re: DTLS 1.3 ACK sorting, and when to clear… Ilari Liusvaara
- [TLS] Re: DTLS 1.3 ACK sorting, and when to clear… David Benjamin
- [TLS] Re: DTLS 1.3 ACK sorting, and when to clear… Ilari Liusvaara
- [TLS] Re: DTLS 1.3 ACK sorting, and when to clear… David Benjamin
- [TLS] Re: DTLS 1.3 ACK sorting, and when to clear… Ilari Liusvaara
- [TLS] Re: DTLS 1.3 ACK sorting, and when to clear… David Benjamin
- [TLS] Re: DTLS 1.3 ACK sorting, and when to clear… Ilari Liusvaara