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

Rob Sayre <sayrer@gmail.com> Thu, 10 October 2019 18:19 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998B7120125 for <tls@ietfa.amsl.com>; Thu, 10 Oct 2019 11:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj8GvCNafBCo for <tls@ietfa.amsl.com>; Thu, 10 Oct 2019 11:19:54 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4B9F4120113 for <tls@ietf.org>; Thu, 10 Oct 2019 11:19:54 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id u8so15875182iom.5 for <tls@ietf.org>; Thu, 10 Oct 2019 11:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ziKek17lTwROmhiUbZxdKcMUL1oj8NbgeLIMdgdEeQs=; b=mshkxXH46V7jQB8W73dqZetHPanY/EsfyxwLM0m2XK2vD1C/rKc9g34OJgNGB353LB 6bz21iHtDnJzliPuQeYs4hLRMK29inwKANVbLpFRWoXRsUYLV4aZSvpYiHh7DTf4x6fF 9gOoaa2pA+XDotM1C71IC3kzlyWQ8ze2P6fm1WImYyxuo1mcWBMbFhNE5ypQ1AuLLTxs EscHzVk6aIgHcWVpWjmZk7t3VGg5zw0wFOXUgY+XsJ/X17TjwQu9jQMSExgiScdxNyKd 1XMWlbbitPAk0Jy7WTL0QhLukWzJQaRcQb+gppu4aEE0VOrbEON1mdeqGXCnlWPIidHD ezFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ziKek17lTwROmhiUbZxdKcMUL1oj8NbgeLIMdgdEeQs=; b=RYBV21LVRjrc1+FgLDuCJt1qlr3zscryv0x5ExFIBUIHyGc989yYqxHPWck531TAao tYZ5ExXSMNBglojLOZmSTyDILC97tFMUz9WScr20Qi84VfNEVXvHz1NQTHzDwdd+/vxi MX0RtxIR2FjqzlEuS08pK/MazBAZO9LtHhj5bDpbydraHMMyeNflD+rrF1Y8dwZVtPLi MmKIFN75smgQVDWd7shKSX2G6zSKB4Ty2pQL0cel9fN2iWXaTtfjB11wUXcDxt5z08cm PGsZfGYUYPXSfXAxSo361KB5EUmGtAt28dNWe4slAXha7X6R/1YlWrssRXYOfJJ2+S3b 2LfQ==
X-Gm-Message-State: APjAAAWQgrUBHCPlCRU4rSqw5s6C4nHW/upsDB+4CtI9KNWigFVVoh5v ZsIxV/63mAXNsDTRPifqYs1Koe+lYjiQq6UXpOE=
X-Google-Smtp-Source: APXvYqzuLdjP36gD5ZZ1/s56od1+ukzdy6LGsuRiKTdHNDENFiMtD/gSWvTXcKyZBkL1UtwVW+zLqdjqT1bccRxzJww=
X-Received: by 2002:a02:c646:: with SMTP id k6mr12453175jan.53.1570731593346; Thu, 10 Oct 2019 11:19:53 -0700 (PDT)
MIME-Version: 1.0
References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <CAChr6Sy9=GbUO19X0vc0Dz7c565iPAj=uWVujLV5P3_QL5_srw@mail.gmail.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <CAChr6Szay7j=czCaYhKGp9bHHmZiArU440hSnvNqNaL+hX2wKA@mail.gmail.com> <F932C81B-95E9-4044-B975-9AFCD09CF7FA@akamai.com> <CAChr6Sy=+qt=KYKfXEkWhBBev88-XEcB4tOZLz9cBf76wsUo2g@mail.gmail.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <CAChr6SyV+qMFs56THZzBxNv5vkQTeBJdG9GtutvVMcyP2CxN7w@mail.gmail.com> <CABcZeBNtv-4=dtrArZwnJHSohrbsrtG53_ynSZdcMp=YeWc9iA@mail.gmail.com> <CAChr6SzCONU2yA87QGNhsx7=5Zn82v1_euBJ-kbRci4vJ32oUw@mail.gmail.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <CAChr6SwdP7iA=ZYg+xa3Ye-b97sekw6=qwJZu2w0n1ZZC9wG+Q@mail.gmail.com> <CABcZeBMLaiPuXhgrExTkdhfaOU_m4g-c+Lq-YmHsKiHyB0jDRw@mail.gmail.com> <CAChr6SznAYZDHFPNHX8Uoyo-Fnx8_uMxCOda1zf37Cxnb5A4WQ@mail.gmail.com> <CABcZeBPoyb5sF+ddH8OU_78eJF5sD2df-+ScHRb1xTYhHRHS0w@mail.gmail.com>
In-Reply-To: <CABcZeBPoyb5sF+ddH8OU_78eJF5sD2df-+ScHRb1xTYhHRHS0w@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Fri, 11 Oct 2019 01:19:40 +0700
Message-ID: <CAChr6SyM_yX36p2W_-seE-9kuJ99RTYEHY_vCRNFjLx3utjogw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a8b156059492725f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cwQyNq_Yp4yi3cOQOqxdUXLGw_A>
Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt)
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: Thu, 10 Oct 2019 18:19:57 -0000

On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre <sayrer@gmail.com> wrote:
>
>> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>>
>>>> I don't think that's quite what I'm proposing. I'm proposing
>>>> (optionally) sending the SNI with a client certificate.
>>>>
>>>
>>> What are you trying to accomplish by doing that?
>>>
>>
>> I want to keep the SNI encrypted in TLS hops that use client
>> certificates, but where ESNI won't work.
>>
>> For example, how is the SNI transmitted in the parens here:
>>
>> [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ]
>>
>> I don't think a DNS-based solution like ESNI will work for that second
>> hop, because the origin tends to be identified by an IP address rather than
>> a domain name.
>>
>
> I feel like we're perhaps talking past each other, so I'm going to start
> back at the beginning.
>
> In the ordinary case of Client -> Origin or Client -> CDN, the SNI
> principally serves to tell the server which origin the client wants and
> thus which certificate to serve. For this reason, it has to go in the CH.
>

In general, I agree with you. But only because client certificates are
relatively rare for end users.

If a client certificate is required, the server probably can't send
application data in its first response.


>
> In the case of CDN -> Origin, it seems like SNI could serve the same
> purpose (say that the origin server is hosting multiple servers), in which
> case it seems like the same requirements apply. OTOH, if the origin server
> just hosts one origin, then you could potentially have the SNI delivered
> later (as you suggest), but then why have SNI delivered at all?
>

Two reasons:

1) the SNI could contain subdomain data, like "username.example.com"
2) if there is a client certificate, the SNI might be relevant in deciding
whether to accept it

I understand that the intermediary (CDN, etc) will be able to observe the
SNI, but it's not clear why it's ok that any passive observer to the origin
should be able to.

thanks,
Rob