IETF Logo Mail Archive

Re: [TLS] should we say anything about ECH in the face of fragmentation?

Watson Ladd <watsonbladd@gmail.com> Fri, 15 March 2024 21:56 UTC

Return-Path: <watsonbladd@gmail.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 212CEC14F60A for <tls@ietfa.amsl.com>; Fri, 15 Mar 2024 14:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RIxotN5XdHC8 for <tls@ietfa.amsl.com>; Fri, 15 Mar 2024 14:55:56 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D122C14F5E9 for <tls@ietf.org>; Fri, 15 Mar 2024 14:55:56 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-33ed5b6bf59so539253f8f.0 for <tls@ietf.org>; Fri, 15 Mar 2024 14:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710539754; x=1711144554; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=t06DSULFz8m0TSIOiqT7zZWYzrQcCxWnjMQs/HkD1DE=; b=EOxsMC7ZgJ/BJfat9SK5VawktS+1wYSlyJFMXUo+YuxLX2H2NP9nByLSEyCpYBLEYN YjvyisLssQCjgo6MeBTxKDaPlQj/xbOU9doRyKNWmEI43sHDffGDms4F07pZVrPn+d+z RB2C7bjsgqJfQB7g0xI1MkzGxlg8s4aSZW1y/8vJP0M99Pd71KNujMozIzaIYlta2paU /kG+GUllNL8UPnfNPzhCOe+vip44vVh2nbuok/rGSwNoRsLMmzCo9XdzFuj6SxJvbOy9 A1JeGjk5zzuMT8uLS39TjqcCJ2WZN8jMhy1zQ3jthOl+T2rv/UaZwVu18L3NXvrNBxCO jGOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710539754; x=1711144554; h=content-transfer-encoding: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=t06DSULFz8m0TSIOiqT7zZWYzrQcCxWnjMQs/HkD1DE=; b=Zi01suqcZOv/eQhNdUGA8yJaCejZ3j3kbD2va0OA2ox+xGxyXDGR7K4KowpcKQywxn P1ylrb83ZKW1gdu85IRd+QJVJDILGSFtc9kP6RgP0HVw05xmZLYxR0bou6a/p0uZGz/5 gazIEtUjWfjFQB0RJKLY/4rLQLnUDAQCzQqBE+glkUoz/MqhsbERFwt28t52k5YbOCyn NDzuN3CpBJqZbrdkC8E7VDbh2ZkLG3C+sU9kf0BlGgpCmgKV7FwqAvnWy5L3loMArY8P RD92Z3R7Rwh/2M+dCtwRtrZn82W2DPtqWPElOqKoZhGHrppGhUeIYdWWfYDS3KTFa22/ hpSQ==
X-Gm-Message-State: AOJu0YzYGfU7Y+1+P4xe3OEtt5GgLvz/prsYhzcwS1aSpQf5w12S6xde RuYDQO/qW5FWtVt/GmiNWbhgtGw8dcDzu2rgf0/cPJQXcqgN1ENbFvD3a2HkyWrzVHXxtfJiUQZ 2D6new1XlTdtz34/C7e7GYkDc7L/sLOON
X-Google-Smtp-Source: AGHT+IFnwSTBDXxI/5/VI4VJsg19LoGdUDt2vk9E/ZIDNRWnM5THpHqLyhaOYvU2ZdfMnd2P07QwkBqA1jPF7/8z+D0=
X-Received: by 2002:a05:6000:2c4:b0:33e:c8a1:148b with SMTP id o4-20020a05600002c400b0033ec8a1148bmr5116552wry.42.1710539754411; Fri, 15 Mar 2024 14:55:54 -0700 (PDT)
MIME-Version: 1.0
References: <71dfb248-1f03-4066-a8cf-6e5439d7db94@cs.tcd.ie>
In-Reply-To: <71dfb248-1f03-4066-a8cf-6e5439d7db94@cs.tcd.ie>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 15 Mar 2024 14:55:42 -0700
Message-ID: <CACsn0cmXD8RCwwiN7jdACXLOOBtv_e1aa3QxKGBYsgKAzpT8zw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jja363gEsc4toziK3g2IG0sjj2s>
Subject: Re: [TLS] should we say anything about ECH in the face of fragmentation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2024 21:56:00 -0000

On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
>
> Hiya,
>
> I think the outcome here is maybe most likely to do nothing but
> since the WGLC is ongoing I figured it best to bring it up in
> case others have better ideas.
>
> I got a mail yesterday from someone who had played with the nginx
> "stream module" setup ECH-split-mode PoC stuff we've done and found
> a difference in how IP fragmentation affected that configuration,
> depending on whether or not ECH was enabled.

I am very confused here. Is this over TCP? If so, why isn't the MSS
preventing IP fragmentation? Is this in QUIC?

>
> The pcaps I've seen show fragmentation of the CH after 588 octets.
>
> In the ECH-using case, nginx aborts the connection as it sees a
> malformed outer CH. In the non-ECH case, nginx can decide how to
> forward the packets as it can decode into the partially rx'd CH
> and see the SNI (which is what's used to decide where to fwd the
> connection). I don't (yet) know what'd happen if fragmentation
> happened in the middle of the SNI in the non-ECH case. (I'd bet
> it'd not be good though:-)

This sounds like an NGINX bug/misfeature. How the data ends up on the
wire below TCP shouldn't affect what happens beyond e.g. timing out.

>
> The reason for the difference is relatively obvious but I guess
> could be stated in the draft: an ECH split-mode front-end can't
> decrypt the ECH until it's seen the entire CH, due to the use of
> the ClientHelloOuterAAD as aad.
>
> I've not yet thought about whether it'd make sense to try to
> buffer up partially rx'd fragments to see if those eventually
> do turn out to be a nicely encoded outer CH - I suspect that
> may be more of a footgun than useful;-(
>
> I think all the exact same things would happen with our haproxy
> split-mode PoC, so this isn't an nginx specific issue.
>
> Cheers,
> S.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--
Astra mortemque praestare gradatim

v2.23.0 | Report a Bug | By Email