Re: [TLS] ECH and resumption - what to put in SNI?

Eric Rescorla <> Fri, 25 June 2021 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3DC83A1AA1 for <>; Fri, 25 Jun 2021 07:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KGhKRSnx_FIt for <>; Fri, 25 Jun 2021 07:39:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 455E13A1AA0 for <>; Fri, 25 Jun 2021 07:39:33 -0700 (PDT)
Received: by with SMTP id v3so12709280ioq.9 for <>; Fri, 25 Jun 2021 07:39:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nCsl5esCph1g/VZyj/5j6Wnj27yIIPY7Kq67CjqMpOo=; b=izIeqmir640WjZZ80BS3D2gq9NK3NEroyq8yHtcfd/q4TEofEh1I5xgpLZlHuiEOtC KXxQ/pEWUDZixbbUEf0V9Pnm2FS2w045ELlxeP9pWwUm1oWMpYKZXS0O35OBl9BWFzDd YyYp6lyWV7lO7k/U2BRaBQDWhilv5FxA+tfxB/tA31c01AfK2gtzZlinUcuSRKvmIO6G vRLX0OQoBHwi5wfb0xP/qQJL2RNxtCck6HqTPT93wcjrwC/e5+aP3sFjMtgfs8BUu++0 tQtPJ3OR/r/4wFWslPA0R7RM0UwOoMWpd/0pR8Drznpa1MbvPov/DnMVQprrCgPlCpgr 46jw==
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=nCsl5esCph1g/VZyj/5j6Wnj27yIIPY7Kq67CjqMpOo=; b=VhgP4PX4INvZEFZQADDvyKUhBo6Xf7sQmeXPGLyisXjho269yYu/00PWUxXhY20a/9 PBjqvjwwxCrJJePHp6rCXqP+n+Dtsl1gPEe4lb3eA7Yj4hECirokTnEml4foFSzX6kZH aGUJ1bdYFRl57pqQgyDyQRkK3Bb4EvcuFEd3Em/E1cbDL+u9DtGQ9z+LEI+02PDtHFKN Dnwp6lsZYtF5ax274Z4ZVU/Y3Wsx5el2bU7L6SmBNmQvnk8dy88hYrtv8Pv1YbwZ+AmH /EbLhZxasw+PqwEtHgHKbKipGe9DWOrVGUwnZC9iFVhMa6bagIan662G51WHLq/vLHmt A/bg==
X-Gm-Message-State: AOAM531DxYNvhBx1D6i+x1BRHPplS04LygJtRm+GIa4Ac8PuAyMwdtXp 6JfNOVm/UfP7fUG4JRdUWMdtdna8I8waw/ft6Ln7Eg==
X-Google-Smtp-Source: ABdhPJz7NPSdBIK0bvlr19EY1KdZtCvCjJBBKlczZ55XJOijwAB6V7uh4bAviaI69DoVbw6v+jw3bRPW36C0fWy+1Xc=
X-Received: by 2002:a6b:f914:: with SMTP id j20mr8632332iog.127.1624631969690; Fri, 25 Jun 2021 07:39:29 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Fri, 25 Jun 2021 07:38:53 -0700
Message-ID: <>
To: Stephen Farrell <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000071d01c05c5981b70"
Archived-At: <>
Subject: Re: [TLS] ECH and resumption - what to put in SNI?
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: Fri, 25 Jun 2021 14:39:38 -0000

On Fri, Jun 25, 2021 at 7:21 AM Stephen Farrell <>

> Hiya,
> If a client established a session to
> using ECH with a public_name of, what ought
> the client put in the SNI when resuming?
> Ignoring ECH, 8446 seems to imply one ought put in
> [1] but that'd defeat the purpose of
> ECH.

> If one omits SNI, that would likely be hard to handle
> for a client-facing server when it tries to route
> to a good split-mode backend. The same could be true
> even if is included as the SNI.

> I guess the client could do ECH again, but that'd also
> be odd, as it'd require asymmetric crypto when resuming
> (which I guess is a lot of the point of tickets), and
> depending on ticket ages vs. ECHConfig key rotation
> times, might cause interesting failures for a library
> client that can't do fresh DNS queries from within the
> library (and might never see the TTL of the HTTPS/SVCB
> RR in any case).

TLS session resumption is soft state, so I believe the correct response
here is to send ECH. Otherwise, the server cannot properly respond
if it is not willing to accept the ticket.

The only real alternative here is to have some way for the server
to indicate that it has forgotten the ticket and the client needs to
do a full handshake and *now* do ECH. But of course, that's
not something that's currently specified and isn't really a great
fit for anything in the protocol, though I guess HRR is closest.


> Am I missing something obvious? If not, what's best here?
> (And we should probably have some text in the draft on
> this too.)
> Cheers,
> S.
> PS: I guess if the inner and outer ALPNs differed in
> the original CH, similar issues might arise for a
> client-facing server, in terms of figuring out the
> right backend to which the resumed session should be
> routed, if routing were based on e.g. the inner ALPN.
> [1]
> _______________________________________________
> TLS mailing list