Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt)

Ben Schwartz <> Thu, 10 October 2019 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4388120115 for <>; Thu, 10 Oct 2019 13:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 pv-4Sut2GtrW for <>; Thu, 10 Oct 2019 13:57:16 -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 F1C931200F6 for <>; Thu, 10 Oct 2019 13:57:15 -0700 (PDT)
Received: by with SMTP id b19so16899732iob.4 for <>; Thu, 10 Oct 2019 13:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o5Wbe0+Jj9EksNCInDVNKUPQGpDelUVJFB0FS7tv/uo=; b=m7iUzvGyd8N+xSn6/fgC1bk5aLlPh799SczN9iW3sxxLUAEeS2dfrsmyZUzEsyy7pE XAgBnRsZ7DyDi1/++Urdmp9YGvyQAJI94g05UBL/XJkBEV8yZ4egIVSlJDyxmdaOWNEk qb8OIi1I+PkgJ9FoR3A3nbjXke4JYVkxob++0zycdTJQAExf7wPaICt08l0Yhgvp2MNY 76QS5TqjQp/hyv1lXZgfBvilF08v8cuQ7CXdWT9ey0Yp1KnTqDQNZar8AzCgABTq6Udc +cAq4dRHr7s43q0aYtuQ86DuaonZQKmHwM5y+6izsD18C+rHtRmZNm0YMf4Gohd9iIj3 Tauw==
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=o5Wbe0+Jj9EksNCInDVNKUPQGpDelUVJFB0FS7tv/uo=; b=eiC3p0d+AQhIdgCUQZTGgpxfC+isjqY7d9YWsr5gP6TpBswdlbkabT4mc1eU2SkSwL Fz3VFsrsnvpenpDjoJWxkcz3cZ1jki7g/xjJjCbLF3xgk3YmWVMZQubNDrSFmrMzSOvC 52pgrxBFCutABK9t5orjh+TX3VGoJ7aG6id4SB/ZnghvPsVrNH2q9fMk/K3wsbEjSZvn z88SegGg0FASZFSASS3OAyC8bLM4KT6+oDKNVWdXUPIJpcw1KZlQuH/I/IpMx2PhXew3 BoNP6ZBpacYUuvJaopULBWB8n8GU2JaHat0rJnwqMyTyMUYJhYJNe0ClSeGi8cO73y+V BNGg==
X-Gm-Message-State: APjAAAW14cjvBq921Df1kttY2XTEWv/yv3Qg9o3SdDaHfSwA9qK1YBSZ lFFK8aW+/2jmsXrWb0rIIAXXLQES5BZRM1NffLinog==
X-Google-Smtp-Source: APXvYqwf/tiWlAt2Mb5yG9epNXxL0B/+epz1XEvLuSj+YNMSHqu2k9Z2xk5LujkDS49+Q/g/EqzqWvRgCFhYVEr7izE=
X-Received: by 2002:a02:c4cd:: with SMTP id h13mr13628683jaj.142.1570741034778; Thu, 10 Oct 2019 13:57:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Thu, 10 Oct 2019 16:57:02 -0400
Message-ID: <>
To: Rob Sayre <>
Cc: Eric Rescorla <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000073f586059494a580"
Archived-At: <>
Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt)
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: Thu, 10 Oct 2019 20:57:19 -0000

Normally, virtual-hosted TLS servers are known to a client by their domain
name, and the client uses DNS to find an IP address corresponding to this
domain name.  The ESNI drafts are largely written in reference to this

I think Rob is describing the case where a TLS client is contacting a
virtual-hosted origin that is defined by an IP address and an X.509 Common
Name, but for which it does not have a domain name.  In this case, reading
ESNI public keys out of the DNS is not an option, because there is no
domain name to look up.  This situation does seem to be reasonably common
for connections where the client is a CDN, and the server is an origin
backend.  (In that case, the domain name may exist, but its IP address and
ESNI keys will be the CDN's, not the backend's.)

The obvious solution is for the TLS client (i.e. the CDN) to support direct
entry of ESNI public keys alongside the IP address.  Users who want to be
able to rotate their ESNI keys more easily should use a backend identified
by a domain name that is distinct from the user-facing origin hostname.

I don't think there's any need to couple SNI encryption to use of client
certificates, nor is there any need to alter the ESNI protocol.

On Thu, Oct 10, 2019 at 3:00 PM Rob Sayre <> wrote:

> On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla <> wrote:
>> OK, I think we've now reached where we are talking past each other.
>> At a very high level, here's the TLS 1.3 handshake:
>> C->S: CH (w/ SNI)
>> S->C: SH, CERT, CV, FIN
>> C->S: [CERT, CV], FIN
>> In order for the server to send the certificate, which, as you can see,
>> is in its first flight, it has to have the SNI available.
> I think this is the disconnect. The situation you describe is common
> (sharing an IPv4 address), and I definitely understand why the SNI needs to
> be in the ClientHello in that situation.
>> This means that it has to go in the client's first flight. But the
>> client's certificate is in the client's second flight. And the client has
>> to have the server's certificate before it sends its certificate, because
>> otherwise it can't authenticate the server and so an active attacker can
>> get the client's cert.
>> If you still disagree, maybe you could show me the ladder diagram you
>> have in mind?
> The ladder diagram I have in mind is exactly as described in the TLS 1.3
> RFC. Assume that the server can't send application data on its first
> flight, and that the client must send a certificate on its second flight.
> Then, assume that useful data can be transmitted in subdomain labels to a
> server that has issued a wildcard certificate.
> thanks,
> Rob
> _______________________________________________
> TLS mailing list