Re: [TLS] ECH Padding

David Benjamin <> Tue, 22 June 2021 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1089D3A1D4E for <>; Tue, 22 Jun 2021 15:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.448
X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ng_OI6ud5gu for <>; Tue, 22 Jun 2021 15:44:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 421B63A1D4B for <>; Tue, 22 Jun 2021 15:44:54 -0700 (PDT)
Received: by with SMTP id x16so686377pfa.13 for <>; Tue, 22 Jun 2021 15:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T3wyzpRPLqn2QyxpnZ0xnPt14B2V0Q4oEwLc0Tc+GHg=; b=MPATZjH0K/54/kjuF7wKCq+gdQV3DCAOcrokhI778i7ERo4rK99Jf3UZuh+1b81hwQ bxr//yPsFtdpOAL4wJdLnI7VecRPYB4XbK9Y7BhIwuFURd9j1750dqxvk3uQ5cIZuuQk yQ4pyrxf+9inkfY74u0NzllJKt0/LWHYyrx2A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T3wyzpRPLqn2QyxpnZ0xnPt14B2V0Q4oEwLc0Tc+GHg=; b=tqGjpxp9sAOWkV1h36wIjUBRfw39+nvAZmAD0F0nTT9ZKlf8Mw38T4XAKExT7Gn4O6 Lc20wGKtZeM/mMAPLr30bZ7L20W8uIMjF1hVJeMmUjnd+D6B1eXej2krpdOY/QiFCiFS BS/ZietNEWVTQ2+PHT1AxAABd98OmukAzJqFxpIErln20JGcFinN6Osfj3LH9kh/oLRz UxVT8wm1yysMOk8xPPOCIGYzoOTty0n6ov02ipw9XXVQ5wef99cks4hXxKhNlWDXrgXx I99bEMIRzzYXUdVAwYLfKwqdDGmk9R6ul4oeo04kaUKVK9te6rl5W9KoMWOgk+mPImiM QZQQ==
X-Gm-Message-State: AOAM532WwZIIhGZfQRHM7O+d1Ip8AIOwxi4eYl5pj5LWu3fyzGzUB9TZ qwQ28GJ7x3TrcCoiX4mtwSYk2nNbD6t3OTMF4yUR
X-Google-Smtp-Source: ABdhPJzF7h6IVODJv9m4VHS0k9Ofqp9g22vwwO2+Y3+tFi6zd6DS7LyIc1IiGIpLYHImjyecdQiauuPWhYQuVrudjqg=
X-Received: by 2002:a62:7616:0:b029:305:f420:49cc with SMTP id r22-20020a6276160000b0290305f42049ccmr3166689pfc.51.1624401893364; Tue, 22 Jun 2021 15:44:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 22 Jun 2021 18:44:36 -0400
Message-ID: <>
To: Stephen Farrell <>
Cc: Christopher Patton <>,
Content-Type: multipart/alternative; boundary="000000000000d4043a05c5628901"
Archived-At: <>
Subject: Re: [TLS] ECH Padding
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Jun 2021 22:45:00 -0000

On Tue, Jun 22, 2021 at 6:12 PM Stephen Farrell <>

> On 22/06/2021 22:57, Christopher Patton wrote:
> > 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.
> Apologies. (Though I put part of the blame on excessive
> githubbery leading to a lack of clarity and ambiguity, as
> is my habit:-)
> I can live with (1) and (2) but only see any need to change
> because of the QUIC argument(s) - absent those we can work
> around things and get ECH out the door IMO.
> (3) is a mistake - a new handshake message shouldn't be
> adopted until after that's been tested and shown not to
> be problematic and I bet it would be problematic as well
> as lots more work

Could you clarify what sorts of problems you'd like to test for?

In my experience, beyond just correctly handling extensibility, the main
problem to watch for with handshake messages is optionality. That is, when
it is not defined what the next message is, your state machine needs to
branch on the received message type. (Although we've certainly done that
before, e.g. CertificateRequest.) The formulation in (3) avoids this
because the message's presence is fully determined by whether ECH was
negotiated. Gating it on some negotiation is also how you handle
extensibility. When we do that, my experience is that the implementation is

What we gain from that is computing padding in the right order. Unlike (3),
(2) computes the padding *before* the data being padded. It also has no way
to pad the client certificate. How tricky that is will vary based on the
padding strategy you wish to use, and padding strategies are where we have
a lot of unknowns in ECH. That seems risky to me. Needing to predict
lengths is also a source of complexity, and indeed part of the aim of (1)
was to remove a case of this.