IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Fri, 15 March 2024 21:52 UTC

Return-Path: <ekr@rtfm.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 595A2C14F69D for <tls@ietfa.amsl.com>; Fri, 15 Mar 2024 14:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20230601.gappssmtp.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 o6g8IVuIby0F for <tls@ietfa.amsl.com>; Fri, 15 Mar 2024 14:52:38 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 BE28FC14F60A for <tls@ietf.org>; Fri, 15 Mar 2024 14:52:38 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-dc742543119so2347075276.0 for <tls@ietf.org>; Fri, 15 Mar 2024 14:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1710539558; x=1711144358; 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=06y/8+z+tmZO69pdeHNQ9A584x9tkGpJ/GTtElI42VA=; b=zKdbqLqmdm5tnkW/amYzYKsOXtndT7HjIrFQFjJOYDFtw0lNFg3fRQUQGkireAbIEZ U2thI4ytAQhRf7Zt+/95DtOJ8CfJ/iJYlTZyxVfrsdJIGqS2lgwMjc7PyUWgePhCza+J f4yT+8Z2Osj3S7tOg1SqkHwUeEbP/zYjVsSEkQY5R22auCzz/LjhMIzJGUWD5FP52DOb mb1pCVW0dVGSYvnAVcf9sDQHsSx0eSTOR3f9ihDph2RuYtePRxXfabffLNBSvsk3TUIo j+a9S3Gt6uJ9n+4kfvROVtVg3ftnGFa0gF9gVXnrxm9lohnoUyja5klFfjil14dkacZs o04A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710539558; x=1711144358; 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=06y/8+z+tmZO69pdeHNQ9A584x9tkGpJ/GTtElI42VA=; b=k2P+zN43zNcGG/7Zj66El1dz7HpBZsgROp4oHS7BjjXy44YFMR6xOS5/PuUrA8HsR1 eBp+ubHnnWWgGK2am9rXQi3l4oMB22NYje+XL4Ylb3rBgvRMjLVg9NQIsF3lLZkLrmFT S9QrLoF72Vdsy7kcrFAj2QvNPE8HPbPLzS3LIlxUV8p5AxPWzf4pL2TVMopxFLP5U/g6 fhBZqbtrnynoXxkEzrCo6RGw+n6U8E/tWV6KDFobrhM6dOEqxRTfI+OB+CvzBkYGpKNS ke6HnDEDbWKLxHzbd31ftRGdHKZWjvWlSp2mrpxI3j6JaYlOhHDfOyy+u7WmC5GDKB1e WeBg==
X-Gm-Message-State: AOJu0Yz4lyXtoOKb8t6YoncMyEZPcELMa1Me8kG/UacZvhxDyhfwIwXB ZZNM0Qd2uAkStzSVt798Bt0Bo+EfRvL+GS9gdJL56E4KPIUONfKJgxkgnyNMDUilgvvQnlzONwd mZ7kboRIwXrRelcd6aLQzvSnkKkNll+1RP8sm44x4YTxrCMAH
X-Google-Smtp-Source: AGHT+IEGIIFHdycI3TBBUnjF4cRBUibQwYhWO3LmVaqUXgkUOUo0ltrP3HdLhNfFqqjSZA+fMDyDWKvgg8cpGcuO0hc=
X-Received: by 2002:a5b:605:0:b0:dd0:467:2e48 with SMTP id d5-20020a5b0605000000b00dd004672e48mr5780483ybq.40.1710539557563; Fri, 15 Mar 2024 14:52:37 -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: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 15 Mar 2024 14:52:01 -0700
Message-ID: <CABcZeBOHvsDER0TH1mjPddknJVf3M4bFLFZB2EvbSOav1wTOOQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b40e200613ba066e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GSGmKvfj0M2aR1yXmfAC3mJV2iM>
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:52:43 -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.
>

Yes, I think the answer is "do nothing". TLS assumes that TCP correctly
delivers and sequences packets. There are a number of situations in
which the packet can be a size greater than 588 octets, and implementations
simply need to handle those correctly.

-Ekr


> 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.
>
> 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:-)
>
> 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
>

v2.23.0 | Report a Bug | By Email