Re: [TLS] ECH Padding

Christopher Patton <cpatton@cloudflare.com> Tue, 22 June 2021 21:58 UTC

Return-Path: <cpatton@cloudflare.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 2D6DD3A1BBD for <tls@ietfa.amsl.com>; Tue, 22 Jun 2021 14:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcCTtrRLQQVL for <tls@ietfa.amsl.com>; Tue, 22 Jun 2021 14:58:06 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990C83A1BBC for <tls@ietf.org>; Tue, 22 Jun 2021 14:58:06 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id d5so629909qtd.5 for <tls@ietf.org>; Tue, 22 Jun 2021 14:58:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t/55P2MJdMyzf3Utjm5GGKgZpxX4oNtJBcBxAKn9XmU=; b=ERzrQQwNB8oLDsmyoEH2Kd6CU9V2zh7R3lcaAWGoazt3XZYYNp3WnZN+NPQEShwSJK BpdhZrTQaIfpZD7BvBiOxIyaXdr4U6JezZ97qYTvXad7M3mySQ1xiaRpgfRzexAjJ2M1 XPNYhlUnie1Vn3x3qx1G8gv9SzwEOS4+nAqjQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t/55P2MJdMyzf3Utjm5GGKgZpxX4oNtJBcBxAKn9XmU=; b=nxKZlOBaETOrYmWXZbq/VtzbGBpHLIH7cTkI90czwxU+ZUvG15HmHEbGdSBKWJDJR+ +htt8Iiyn3KzZ4iZbTKi1K690y6fyVAHtpdhYZDy2UDkil8+cbC3xe6ax/W0G7OV64Oa POiR1G370LF74t1xBBhJfCeiKCWtNcirYrNq/ilADbKLClYQOWy7yMIBHAdiHwxoi+LF qcHL8HGNQHU3l5wclIMMO3wlpRIOoED6nD2D+766cZ5Fc0zLigYTW/ey18SBf76cJox4 owgizv/LkIGBRCyaWIiBCa+cs5KGkHe/T2YxjbOcs3DeA7iMjx4KrlV3HKRuIQNLyem/ X8Ig==
X-Gm-Message-State: AOAM533S/IZjZGtjV7/o/cpr9nNGd0+jntbZl+Ld8SPp4okwDAI9KqSh ZKYhOWe/ZApDesk57xAETomLPMLaZRWWpV6O6pxhvuWHO2E=
X-Google-Smtp-Source: ABdhPJzLzkyAJ0EV2x057zOKCzsD3ZvC3nJBcpF2cqeGtRVLtXn3f5Q6M/6BFM1nPb+2Ysg/Z47omPXPkmWAQUfNwOQ=
X-Received: by 2002:ac8:dc9:: with SMTP id t9mr818730qti.293.1624399084927; Tue, 22 Jun 2021 14:58:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAG2Zi21oLUmoNLXVD7QuOOLre4XZtxJxt=2SH_ELkigdUT9m6g@mail.gmail.com> <8f249b27-7ea9-d044-fb87-e2af6b26175b@cs.tcd.ie>
In-Reply-To: <8f249b27-7ea9-d044-fb87-e2af6b26175b@cs.tcd.ie>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Tue, 22 Jun 2021 14:57:53 -0700
Message-ID: <CAG2Zi21fgKV+CmqHiaOYCgd7Cf6-Zpj7oqQuMZmuJrxYA7Yxug@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006e63f405c561e2cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NUetelM1UNeU3Rso2c5RTP_tPf4>
Subject: Re: [TLS] ECH Padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 22 Jun 2021 21:58:11 -0000

> (1) aka #443 is the way to go here I think. (Such an aptly
> numbered PR has to be accepted I'd say:-) I'm only convinced
> of that because of QUIC, but that seems like enough or a
> rationale.
>
> I'm against (3) - it'd break too much and cost too much.
>
> WRT (2) I'd prefer to drop that extensibility rather than
> try use it because it's there.
>


Just to be clear, (1), (2) and (3) are not alternatives to the same
problem. (1) solves client-side padding, whereas (2) and (3) are
alternatives for solving server-side padding.