Re: [TLS] ECH Padding

Martin Thomson <> Tue, 22 June 2021 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D0863A1DDA for <>; Tue, 22 Jun 2021 15:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=z3Rnli3H; dkim=pass (2048-bit key) header.b=MpnuajtY
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0u2VQVv1DVS4 for <>; Tue, 22 Jun 2021 15:55:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 481F23A1DD7 for <>; Tue, 22 Jun 2021 15:55:37 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id AE51F5C0004 for <>; Tue, 22 Jun 2021 18:55:35 -0400 (EDT)
Received: from imap10 ([]) by compute4.internal (MEProxy); Tue, 22 Jun 2021 18:55:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=cTWwrWXhCutBbd4zmylpO/RrmnZDDZE aiZXsvsJsyTE=; b=z3Rnli3H66rckAgA1VFW+M6BWuKsVqbdugLbKl/7tJTzr7k hxGag92WlRAl05hjErujHAOYIkJEwA03lhmzB+4/8l7iFTFgaX3wz+aehUsVOzlo B/LU9ZO9x0tyrYHjUsHfa1vuju4H+JKrXW73rXf/FUIG6fatyvelf9j71UD/2GPG rUFlu9vfbJ90QNHTNFqW6lfits2KmsNi9ukqo4b7sEUKO4huhTt6FOD5ZLogIy45 EzieP9EG1pJdh48Tv1nNmSrLFoIaY4NH3tqUrS0a+Esb5vIIgK5iaf/7Al8crMa2 b3EU5+Sn8UqIOcxSRLJf4UUrxCrj7vj15T3oWiQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=cTWwrW XhCutBbd4zmylpO/RrmnZDDZEaiZXsvsJsyTE=; b=MpnuajtYCsDW+o2MOybxYN Hl3Av8BPONbaYE/LudQhmtyXzCLzAf9gPHM+Nt+kme6s9QdHeQuLKt/wn3UA90PF x7WCs4luu0PxzmN98iIHt8NmXDcOi2WBEF+0j5Q4vZq16lYz0MOoF6BQt5Mj7A++ bgYyLiRs5ZK72kzDI+NFiMeqT2vzd08fxpayLPgXaJHT3wHbDhnmssikGxeKhMVt 1x3o/C1Xmze1WDLBEcoSGqeLd9A08e2+A0aJqwHiURyvxsT3CqYhZFE/FK+wbO2L y4nWEiRI7LOE3i6Ru85lDouXOXRDuYAgAtEi/yOZATSh935NAwji4zod6D4YgQaQ ==
X-ME-Sender: <xms:Z2rSYHyUndbidpqDIYkAzHRtbmCvw7Smw08Abm_cv-c3SgxX0LPveQ> <xme:Z2rSYPS8xaa2XBK7q4swkuUcjB_Vh4uwHo-6gZE5SNjtDkRWA3Yh4dfl9llVUwkej 3iJONytAea9z4SluNs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegvddgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeffveekgeetvdeuvedtve evtdeuleegveejhfehgfetffeiiefgveefleffteeuleenucffohhmrghinhepghhithhh uhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:Z2rSYBUERWqsBArYHcFPPVoCXxrdFz7P_LLXdQtPB_AHw_LiHGKCfA> <xmx:Z2rSYBgHTX_RhJBNbPHqoqUleXqqv3WYMqlodT1Ge6z9xXZpzDcyrQ> <xmx:Z2rSYJBZj_5_TlXtcsY5c8dXJ2KHljTq16__SzUxv33Y_fE9r9OskA> <xmx:Z2rSYMOSxY8V6uAA0GxtTG4lFpmhmm-aOdB5m2UzNWj8bIgmwCru4Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 20E054E00AA; Tue, 22 Jun 2021 18:55:35 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Wed, 23 Jun 2021 08:55:14 +1000
From: "Martin Thomson" <>
Content-Type: text/plain
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:55:43 -0000

So I like #443 as I have said.  It simplifies padding for CHInner a lot.

I also like #457 (option 3).  My initial reaction was not positive, but I've come to appreciate the value of it.  I don't like that this has to be in the transcript (QUIC doesn't need it by virtue of a design that separates protection levels from content type), but as far as solutions go it is the easiest to implement.  In other words, it has the fewest awful shortcomings - a benchmark that has come to define ECH.

On Wed, Jun 23, 2021, at 07:27, Christopher Patton wrote:
> Hi all, 
> One of the last design questions for Encrypted ClientHello (ECH) is to 
> decide how to pad encrypted handshake messages so that their length 
> does not leak privacy-sensitive handshake-parameters. The current 
> approach is to insert padding into the record layer as needed. However, 
> the consensus reached in [1] is that computing record-layer padding 
> based on the contents of handshake messages entails implementation 
> complexity that is untenable, particularly for QUIC and DTLS. The 
> alternative that most folks are happy with is to insert padding into 
> the handshake messages themselves, as this prevents details of the 
> handshake logic from bleeding into the record layer code.
> There are a few PRs for adding handshake-level padding that we could 
> use feedback on.
>     (1) Adds 
> padding to EncodedClientHelloInner, the message that is encrypted and 
> stuck into the ECH extension of the ClientHelloOuter. This prevents 
> leakage of sensitive parameters in ClientHelloInner.
>     (2) Defines a 
> new extension, which the client sends in ClientHelloInner in order to 
> solicit a response in the backend server's EncryptedExtensions message. 
> The server''s response contains padding it can use to prevent leakage 
> of sensitive parameters in its first flight of handshake messages.
>     (3) 
> (alternative to (2)) Defines a new handshake message, Padding, which 
> the client and backend server always send just before Finished in case 
> of ECH acceptance. One advantage of this approach over (2) is that the 
> length of the padding can be evaluated after the 
> Certificate/CertificateVerify messages have been chosen, making it 
> possible to account for sensitive parameters in these messages without 
> needing to buffer the whole flight of messages. The downside is that it 
> may add complexity to the state machine of TLS 1.3 implementations.
> There are some open questions regarding how to compute the padding 
> length, but these should be orthogonal to deciding the mechanism.
> Thanks on behalf of (some of) the contributors,
> Chris P.
> ____
> [1] "Handshake-level vs record-level padding." 
> _______________________________________________
> TLS mailing list