Re: [TLS] ECH usage indication: alternatives to trial decryption?

David Benjamin <> Mon, 17 August 2020 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 542C83A11F1 for <>; Mon, 17 Aug 2020 14:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.498
X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 tUQc_MVFmeu6 for <>; Mon, 17 Aug 2020 14:21:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E031B3A11CE for <>; Mon, 17 Aug 2020 14:21:27 -0700 (PDT)
Received: by with SMTP id u20so8875150pfn.0 for <>; Mon, 17 Aug 2020 14:21:27 -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=yg/ljB5BLrWJDHzA+dnUPYfIgC13jJm/ysvgxvgJ0lk=; b=iucHD+Bk8yq5gar3FK5KV5tWFg/b/IWGMBjfGxhAVC74u+2lyFyd3kim05fv7bsaHn wIar88xQsHw+LyuZAxMiyhZaTY/bSHJ5XSPbGbOlzCBD10U1ttBkfBGUDpGeT33khdyf DjR52XJQ6YP3vPsyE7w0xDOJC7HGpCskr4gUE=
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=yg/ljB5BLrWJDHzA+dnUPYfIgC13jJm/ysvgxvgJ0lk=; b=KeBS03zls1J/SzZC5udvSlyykgWadUI5dX8ivb8LYOYc0FW3VBiK6pjXA4U3fhz0HD ESD3P2YkzVUoQRTxzX8xeoQQtCKajxtq6rhnPiwdttMgmSnHbHc6TFV3hStv1puRjEsY /j01KpXlwrzGFbPtIlm9dkF2kYUEyUEJV8+t1EN1F/GbAEHEYsUigmWAWM2X3qsWv6ji yc7WVuHmXjD2SLzp+ISIL+DxIk3HBAxnQZnV39LuowvYBlVwUjH3vLxCwhPK8gZfpLI7 hklTWmkNHn+ylEb3FXGME0efmYD0ivE4hEzwRX7URKArUt4IcJpGpDMTfWYOlyMtaKB2 4IyQ==
X-Gm-Message-State: AOAM531Ihw0F0zWEHq/q4G9PiVx2sN8cY7uljmxfQJuBm7mR3gnuZdrx 1IDdSFnbfUDyUEB3D9hRFo6Tze190ejjLrnblSuS
X-Google-Smtp-Source: ABdhPJw6aBxklvvCooDfDWx/72TpEafqqtYzUb9IJhJkiUPELEp/E9PJYXpJkLP7UyjX1VGIWJo8HNvbiDF+zmdOTGQ=
X-Received: by 2002:a63:31c6:: with SMTP id x189mr8113461pgx.182.1597699286937; Mon, 17 Aug 2020 14:21:26 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 17 Aug 2020 17:21:10 -0400
Message-ID: <>
To: Christopher Patton <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000007529a405ad195aff"
Archived-At: <>
Subject: Re: [TLS] ECH usage indication: alternatives to trial decryption?
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: Mon, 17 Aug 2020 21:21:29 -0000

Thanks for writing this up! We've been pondering this subject as well, as
part of identifying places where ECH and QUIC interact interestingly. (The
other being the padding issue in

As with the padding issue, QUIC replaces the record layer, so all the
handshake/record-layer coordination here must cross the TLS/QUIC public
API. TLS must configure two different keys for QUIC, then QUIC must trial
decrypt and report back to TLS which keys were used. In contrast, something
that lives entirely in the handshake should apply to QUIC without

I think in essence we’re running into QUIC sandwiching itself between the
TLS handshake and records layer, despite that “interface” not being quite
fully understood yet.

(I'm not sure what's IETF email etiquette for joining related WGs to an
existing thread, so I'll forward this separately to the QUICWG, so they can
join the discussion.)


On Mon, Aug 17, 2020 at 4:55 PM Christopher Patton <cpatton=> wrote:

> Hi list,
> In the current ECH specification (draft-ietf-tls-esni-07), the server
> provides no indication of whether the inner or outer ClientHello (CH) was
> used. This means the client must do trial decryption to make this
> determination, which creates implementation complexity and potentially
> raises security concerns. I was hoping to get your thoughts on a couple
> alternatives, which strike different balances between implementation
> complexity and other design considerations for ECH. Follow along here:
> Thanks,
> Chris P.
> _______________________________________________
> TLS mailing list