IETF Logo Mail Archive

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

Watson Ladd <watsonbladd@gmail.com> Thu, 10 October 2019 16:07 UTC

Return-Path: <watsonbladd@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 C401B120804 for <tls@ietfa.amsl.com>; Thu, 10 Oct 2019 09:07:20 -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 00o6-DZrQMh1 for <tls@ietfa.amsl.com>; Thu, 10 Oct 2019 09:07:18 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 54D4712080E for <tls@ietf.org>; Thu, 10 Oct 2019 09:07:18 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id m13so6747099ljj.11 for <tls@ietf.org>; Thu, 10 Oct 2019 09:07:18 -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=CUa/6Kl62X/P5MUrCCdyWFzhGSGUKAjB9cE/qgQgu4s=; b=VnZyJkrP6prQKz8Y8rEKmKL+z/ndH9JJwY2Ev+f1Zy3gxwkQi1NMpAGVjHc28O4NJW iACLIXV+EckQNzjV3RCAKI44dSepujzC+bkqqqwoCxUP5k0fD8eTHF/F/OxPSz56RIBz dHLkRj1J5Uw5Mx/IZ1EWIl0ux+508Kq70ZVhJoxkY+NjYd3tjnRjrVi4kubKXHMKaNlR RrVJi8jrg0xf5Wq8AzGqe2ey6+R8GteNk/ucj5WnPqv86rtbfu5If1zYwpqf5FIN6XK1 cRoYNdvKrYG5RFsMsEN9zBstzUZ2UhbECME6NLxEIF9fTZkW7X31t2TJ960WbdhfmHeI tOMA==
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=CUa/6Kl62X/P5MUrCCdyWFzhGSGUKAjB9cE/qgQgu4s=; b=Sg1R484n0nka8Bv4v1btE+32kktvpMFC7/bcHt8+Ml2TxoD33N6jXO3BVsIfo1kwJn TDjvm5PwsyYbwNFpRgzckJkd9jXtR6VTo2YTfSGXRuxyeZTJIOwF98n0MvICMUenO8Ki FK1nN6KmJNVeO7Q9mUyr+8WLZQ0sPehgvQybJNpAAayaGMs4bSV4V/mtU5VmhBx0j47C HKfi9JnNMmLgooovnG32sFxxQGqEwtYeEHZECwarr4ntEEwCB8rrqftODIOoqA6HS5LW 7KoAYv33wRu3rH3Qa2GWLGk4oU2+HC2js+r6LbMPQ5snTe1NM1xFoXEFdx6jDNu9orPu tYDg==
X-Gm-Message-State: APjAAAUbYtji55X58XKZcvo5WXs59MrH0D1a5sOJald3Oiv+hQVX3mzc g0kV69NTERfribr1lCS4uTwqgb2DQyxTDRflBdw=
X-Google-Smtp-Source: APXvYqzvR1iO/OaglcWrq27o9es4T79eyHPdTtIYwCPendAiT3IGJ4AdJNHbAsIbTcgufmDYrGpMPnXD7GV+4wPgi3o=
X-Received: by 2002:a05:651c:120b:: with SMTP id i11mr2971972lja.123.1570723636376; Thu, 10 Oct 2019 09:07:16 -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> <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com>
In-Reply-To: <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 10 Oct 2019 09:07:04 -0700
Message-ID: <CACsn0c=VC0cpK_PBxv9MtALX5RmDfsfsz2y_6sXshxmVv5RY9w@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Rob Sayre <sayrer@gmail.com>, Eric Rescorla <ekr@rtfm.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000062f9b90594909874"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LWcFTLXfNDUgOzEKbtXulX_wM5I>
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 16:07:28 -0000

On Thu, Oct 10, 2019, 8:54 AM Salz, Rich <rsalz@akamai.com> wrote:

>
>    - I want to keep the SNI encrypted in TLS hops that use client
>    certificates, but where ESNI won't work.
>
>
>
> I have some questions about this, see below.
>
>
>
>    - For example, how is the SNI transmitted in the parens here:
>
>
>
>    - [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin
>    ]
>
>
>
> It is transmitted in the clear.  There is no architectural reason why it
> could not be ESNI.  But in my experience, there’s not much point in it,
> either.
>
>
>
> What do you mean by client cert?  The CDN->Origin hop cannot present
> original Client’s certificate because (in general, maybe there are some
> exceptions) the CDN does not have the private key so it cannot do the
> necessary crypto operations.  That’s the right thing to do, otherwise
> anyone could present any client cert and claim to be the Client.  Instead,
> the Client certificate (or parts of it such as the subjectDN) are presented
> in newly-added HTTP headers.  The origin is configured to trust those
> headers, depending on the CDN/Origin relationship – it could be the CDN has
> it’s own client cert, it could be via IP filters, etc.
>
>
>
>    - 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.
>
>
>
> In our experience, the origin is identified by a DNS name.  I could
> double-check, but I don’t think **any** of our customer origins are
> identified by IP address.
>

At least one customer of the CDN I work for  (namely my own website) uses
an IP address.

Shared hosting behind a CDN does exist where clients of the service
provider are signed up to the CDN, and it might be interesting  to use ESNI
there but the privacy risks are less extreme absent a global passive
adversary. Protecting client to shared infrastructure is what ESNI aims to
do.

>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email