[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer
David Benjamin <davidben@chromium.org> Tue, 05 November 2024 15:24 UTC
Return-Path: <davidben@google.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 24A95C20C8D5 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2024 07:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.403
X-Spam-Level:
X-Spam-Status: No, score=-9.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 Yg2gpKs9H-pm for <tls@ietfa.amsl.com>; Tue, 5 Nov 2024 07:24:35 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C63C1F7D9C for <tls@ietf.org>; Tue, 5 Nov 2024 07:24:35 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-539fb49c64aso7846647e87.0 for <tls@ietf.org>; Tue, 05 Nov 2024 07:24:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1730820274; x=1731425074; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hpCybRuop4Tsy1R4GoUdOXhvCrWQaQZ7K02Ek+GL0w0=; b=bbOnExts4fBZ2AtXMPBPLmWQXqUEpUwU+MkMOtwQ5v3AdfRcJau++xMWlCdL+gpjdK abl20sgHgVrt4jF+mi2efKIUkkdItmX7cJsa6fInxJrMlbLfChjuQkGcbJatYY4waKxP 3Oq5Lu1Rbx4Ad6p/c2S3Tnlh+51hOft5y+yZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730820274; x=1731425074; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hpCybRuop4Tsy1R4GoUdOXhvCrWQaQZ7K02Ek+GL0w0=; b=kosUN3m9Evc8tQ+Mjs4vnkwMgkCE6NUoWHdDpChft92Dc7BQm07RkZGmWCtYsLUqkE PioBCf90o0uSzpL+KqKwKVrDSlYPNPHLBVIT8O6KR0/O8zQ8by40WcSliKjN0WK+9H6H V2osuP3zYoIndgKBVZuJRHVAuJ9e7k1F2DotQ+QIyot7X8KxtZcBM1CcR3Uru2B0j2KA NEVc+ddV7voqqtPcvdoNRPu0SfQEAX1rUdu35295TAohmVohKQdCYvx2SsdbUTOY25RW Epp61uAWFrvjJ3ANt2RvMHsIvLxmcw1J5NXYzHqLFGUjN4qf70DCherv8CMgZYp/UCKX yIUA==
X-Gm-Message-State: AOJu0YzDjE81BwNfG6YLn84CXQqwpHlOIvIpuuMHyl4VuBgDDYa5w8xe w8vg2hnEBvzZaSr4b2QvXB5nLgtdsqbQ0/wFr5mEdHlYQSU6772ePCUD2YqotmF80lEQtjCrc5/ 0Yiu20cg+uhRm5s+lKZjGBsG1cvHZV6B5R5vLIey9s8gpe+zfvobY6g==
X-Google-Smtp-Source: AGHT+IHohHdwjxv/PgS9kTqsA7FwzTkyGDF6/1RLZKBK5q5l5lRVjG33JrURRicHejXF3li9Q5F4C8vYJB2hP+zT22E=
X-Received: by 2002:a05:6512:1314:b0:52c:deb9:904b with SMTP id 2adb3069b0e04-53d65e0b4ecmr13081605e87.38.1730820273328; Tue, 05 Nov 2024 07:24:33 -0800 (PST)
MIME-Version: 1.0
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> <ZyooiLIxka6ZQc_x@LK-Perkele-VII2.locald>
In-Reply-To: <ZyooiLIxka6ZQc_x@LK-Perkele-VII2.locald>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 05 Nov 2024 15:24:16 +0000
Message-ID: <CAF8qwaAnxD4RnAgGPfLOa22gkC=YftnDLyJiu+3Hv6b5Ou6HeA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="000000000000906fb606262bffd7"
Message-ID-Hash: C5WTUWW4E5FUT6QDD2VVD65QB67A6DGL
X-Message-ID-Hash: C5WTUWW4E5FUT6QDD2VVD65QB67A6DGL
X-MailFrom: davidben@google.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
CC: "<tls@ietf.org>" <tls@ietf.org>
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/k21w_7MMPxELTy-uWQJ2Zi_8hcU>
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 5, 2024 at 2:25 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > 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. > Oh yeah, KeyUpdate as specified in RFC 9147 is completely broken. I started a thread about it back in https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/ > > > 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. (Guessing by NAK you mean replies with an empty Certificate message?) That is a good point. Until you've gotten the reply ACKed, you also need to store enough information to reconstruct that. Yet more things that RFC 9147 should be spelling out. Actually, for that matter, what ensures that the multi-message flights in a post-handshake transaction are consecutive? When you reply to CR, you might need to send Certificate + CertificateVerify + Finished. Both sender and receiver need to agree on which CV and Fin go with which CR. Assuming they're consecutive seems to be the only way this could possibly work, but does the document actually spell this out? I don't see it skimming 5.8.4. David
- [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