[TLS] ECH Padding

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

Return-Path: <cpatton@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8B2DF3A1A71 for <tls@ietfa.amsl.com>; Tue, 22 Jun 2021 14:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_BLOCKED=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gmdy41gIH8IL for <tls@ietfa.amsl.com>; Tue, 22 Jun 2021 14:27:29 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 2AB4D3A1A6C for <tls@ietf.org>; Tue, 22 Jun 2021 14:27:29 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id r20so586663qtp.3 for <tls@ietf.org>; Tue, 22 Jun 2021 14:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=/o84KKw+s94OrI9f8mfS/bxI2Rz57oOCJxPsPwGZPeU=; b=IhPB4+lL3aFt1xYz4/CHCdCTyXoJaUyGYnkX0RZ0TdOkMPQyQgBrn7P8J1ieQaS9F8 0rCGsZPU2p+96ApdO/wfkHQAyhEaLbXkxaZ2gZWdNzJXbWZWlTlCjec6FKeEL+I/5EUH 0dSP8nAY9zzEjU+oG2MA7t96oUaYmN2F+Q75o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/o84KKw+s94OrI9f8mfS/bxI2Rz57oOCJxPsPwGZPeU=; b=kV9S4TtlgFZ+WZcZ7ZWjmtwH9qSRy+zDh5tGOf03705YYDOkcSnT6FeNX7p8aUZ55M gvSYeRageY5VtpacCb6B34HAnHyurwYwaFnpm1yOL9cqx46sE+vWmAZoCyVv6JOJj7Ld BM3Tdz6asLI+LsEAsIa0iqTFIa7f/bUaeZW/2iltoCrN04UNwOBuchVuWbXOC1xO9Lb5 LQ17hGwV+RyXLrsLaFUJiSXdKLCa/a33V6wlKP+RoBak5afgxIkrzMkr9q5PHKy4c1W3 ln9Enf/qtnnQEoRC8+BwJGWF42Dxd/6M9O3gLdi5OtFmWO9d1pdLLCp1QzDB6mGJbW8Q dY7g==
X-Gm-Message-State: AOAM533qvP6HIQ0X+ofZc0qvt6/h76ngjVP/EV9+jDcU1mMK8zqXkLbY D7xC3wpMBFAJERortDgJzoyynPoH8moQC9t/7/mInBL8i8Ofwg==
X-Google-Smtp-Source: ABdhPJz8KsN1ZABIichEne8YVrBmCcfxdRwhdHh43HHgBQKXqa1yCXXTE++EGmern/GrvIdQhyKmr9hCVa3H4upcdKc=
X-Received: by 2002:a05:622a:1651:: with SMTP id y17mr766163qtj.388.1624397247418; Tue, 22 Jun 2021 14:27:27 -0700 (PDT)
MIME-Version: 1.0
From: Christopher Patton <cpatton@cloudflare.com>
Date: Tue, 22 Jun 2021 14:27:16 -0700
Message-ID: <CAG2Zi21oLUmoNLXVD7QuOOLre4XZtxJxt=2SH_ELkigdUT9m6g@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e83c1105c5617434"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Cpr3Vz9LIfnHNqdV56B1oSkWA2s>
Subject: [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:27:34 -0000

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

There are a few PRs for adding handshake-level padding that we could use
feedback on.

    (1) https://github.com/tlswg/draft-ietf-tls-esni/pull/443 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) https://github.com/tlswg/draft-ietf-tls-esni/pull/313 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) https://github.com/tlswg/draft-ietf-tls-esni/pull/457 (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

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."