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

Patrick McManus <mcmanus@ducksong.com> Sat, 12 October 2019 14:10 UTC

Return-Path: <mcmanus@ducksong.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 8F4C4120074 for <tls@ietfa.amsl.com>; Sat, 12 Oct 2019 07:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ducksong.com header.b=FNA23Tjh; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=NnqLyQn1
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 5LCeNxkEvoi0 for <tls@ietfa.amsl.com>; Sat, 12 Oct 2019 07:10:00 -0700 (PDT)
Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E7C120019 for <tls@ietf.org>; Sat, 12 Oct 2019 07:10:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1570889400; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=NzDGqd0IMaw0nPmCyf4J8tqB7TNM47Xz+2qVqHlIa0bL+HIe++Eg4LafOFl+gBoZ/DcOU8aZ++xLn QiRwNrNWxTmfJ8If5r7fwiGKMB5Fow/oAy+0xlLKW1Ly0fJxNBQWHasJ4sIaFh1DU0MRDjWe+m0anK KPTPYCX+tIjeNjQVLXsB/JnxeKiOAAP8QTR7r3dLKN2IIdZxqMIepBLuIvChgV80T/boMjmaQK90qn /mUlUkZp+GklLZh2HOrmvILf5eL36WhSKT3B+yQntWL6kUuOEDMk048YAoc/YPKlIU2YkFOkV5V8e5 m7KzbP2wqSTW949r9XcN2yRpGl8NV2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=oD82RcvQUGc1/XkJa9GwHDDWprlq5LcxYG4ZUVc9sdo=; b=QVM7SYsv32KKcYFnGb++lyoXqmUo3v1CtM8EfGHZqNaU/rhxCuSmcvLEfO+KIUlUieE6WLda/uV2t 39hi3X8G6mDhtBY6PUnu5uTI9sOAbJR5wHeOl3t552HNHs4lBImsJ6iC58ho0F7GI0dTbSbVIP4hrN sECD7NZGmm5MQ43I4eRWK1zyaRbwlQSBueEWTN4tZsmKgTWH0uZMjbjd2ZDTf6zSmZ9tUncM4OkY0C mjEhK3HYHqbDwkEaxv6+ziYbDRgx3+OVF41T1H5WrGVb0iXVOzMlqAMmqgudZEi4j6P0u5QX7sWwnF VgXOMnxA8mLuY0GgFnsMN3QpRRfwmRA==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.54; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=oD82RcvQUGc1/XkJa9GwHDDWprlq5LcxYG4ZUVc9sdo=; b=FNA23TjhI4d+5/IRNYROnPppGY7icRisXEWmAB+iTRk7r7hXVT1ci3RfPrV+v9Xm9A2xgFt8u8AWp 4PPYktfgmFZmAYS5vrj+iOaNfZ9opaVk3kV3Wu4dp9m8eEUQDP0N012/axN0KbrugvTlp+ABVIX9/C Rh/NMCfdUxUETT+U=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=oD82RcvQUGc1/XkJa9GwHDDWprlq5LcxYG4ZUVc9sdo=; b=NnqLyQn12dw2SUqeFmxwQtcfxzNiTrEqp62kPkGRhDO7evqU0ad5NHdUY8GQt0v1nllz8644s3hBb s7+z0KZjroqdjMx+3BsDjd5gf2/n7co+jepyc98iUXLcRkmRKS2Fiio6dSW6FhJ8SD6Rz3uWEEgA7p r3LB0UOatFzytn0fca9mwndjbqWfLV0yYiMk4ev2hmzI7uUPAqP4pIDd26q8LmeagA2FYBDUzkvX/P TBM8xxihviPVVpTKq2Q3LB7fme4LlCZrxjHUqfhLKz+CHhOg5OV4CHwWIvMQ4L1tv1HJ147yGGV3DO nIWsV0JS9ebovVXeFqVBnAwZd2cknrQ==
X-MHO-RoutePath: bWNtYW51cw==
X-MHO-User: f682537e-ecf9-11e9-955f-dfabc1efb494
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 209.85.210.54
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from mail-ot1-f54.google.com (unknown [209.85.210.54]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id f682537e-ecf9-11e9-955f-dfabc1efb494; Sat, 12 Oct 2019 14:09:54 +0000 (UTC)
Received: by mail-ot1-f54.google.com with SMTP id s22so10332201otr.6 for <tls@ietf.org>; Sat, 12 Oct 2019 07:09:54 -0700 (PDT)
X-Gm-Message-State: APjAAAXTtbctfUjuSWsUJebJWZZZ26cDSJunauwr7swjO/3Ow7a2Zc2w WZRGUT7CECYug8YgiUTZ1xDc/VJ8o1OrbAKPQfI=
X-Google-Smtp-Source: APXvYqzinsBE1qLmpN9KZ9arAz5p3ng+bBuDN2EGPLx407j/153lQ+QDpxmtH4opWKQsEI3N2vw3R70+x3lkqj3N+Qw=
X-Received: by 2002:a9d:66d2:: with SMTP id t18mr1262930otm.154.1570889393625; Sat, 12 Oct 2019 07:09: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> <CAChr6SyM_yX36p2W_-seE-9kuJ99RTYEHY_vCRNFjLx3utjogw@mail.gmail.com> <CABcZeBPkQjsRr83PYyvhGF8ByeC1gGFWQgofrf=dZmfAfm7UJg@mail.gmail.com> <CAChr6SxSP7LbYkK50-KJu4H4VLLyHpuuK_+N_WZs5Ky5PNnM+Q@mail.gmail.com> <CAHbrMsCiC_2PJNuvYMO+owJC=zJgbYzEZD1kkW38c8yw+qe0nQ@mail.gmail.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> <CAChr6SzAvAcyebuDCGzHeuSMqUQE5mC-XjTx2EwFb-OF65b-aw@mail.gmail.com> <CABcZeBMSGv3q_zYZzzYtWfhuM0C2diLU6i7Z6m7E2+3zbmyoJg@mail.gmail.com> <CAChr6Sw4Z2qsgVNUzjHkLeodtk7ZomkC3cbTwtQ59NbiaWCwfA@mail.gmail.com> <D0B30308-AF91-4597-9057-337D402FCF63@akamai.com> <CAChr6SzQDSGLrF1DUuMJpxexuWUsCAq8+DE9Ajp8a1B7maQfhQ@mail.gmail.com> <4BB4C376-D4EE-4C3D-87D2-3611E6285801@akamai.com> <CAChr6SyKdUfexnt2d-RAM-ue0ffTdOUo4ik71xUTVMk3P_ayyg@mail.gmail.com>
In-Reply-To: <CAChr6SyKdUfexnt2d-RAM-ue0ffTdOUo4ik71xUTVMk3P_ayyg@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Sat, 12 Oct 2019 10:09:41 -0400
X-Gmail-Original-Message-ID: <CAOdDvNoUfN8m5hdR04ckiaeSKeEffEpAY99ZM15qR-_Qwvx81Q@mail.gmail.com>
Message-ID: <CAOdDvNoUfN8m5hdR04ckiaeSKeEffEpAY99ZM15qR-_Qwvx81Q@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049e0a40594b73098"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OWT9roSl-kqh9fwSbDOkAgorrok>
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: Sat, 12 Oct 2019 14:10:04 -0000

some thoughts after catching up on this thread:

* cdn -> origin ime generally resolves via DNS for the same reason you want
anything else to resolve via DNS: a level of indirection is handy for
management. Occasionally it bypasses DNS for the same reasons you want
anything to bypass DNS: a level of indirection adds tail risk and overhead.

* origins sometimes have reasonable potential for ESNI anonymity sets
themselves .. cloud hosting environments would be good examples. this
should be encouraged.

* it seems pretty unusual that a CDN and Origin would share keys.. the
major use case of the CDN key is to cover an anonymity set that is a
significant number of distinct customers.

* using one v6 per origin (when you've got multiple origins available)
isn't a great pattern imo - not only does it make ESNI rather useless (with
an anonymity set of 1). but it fails to leverage the handshake and
congestion control amortizations across origins that h2/h3 can and will be
able to give you. We've built all the necessary http authority muxxing
stuff into higher levels with SNI and HTTP at this point, there's no need
to force it back into correlations withe the transport addresses.

* a few folks do like to authenticate the cdn to the origin with client
certs. That's nifty - but overall its pretty unpopular for the same reasons
managing distributed keys are always unpopular - its a hassle to manage in
the wild certs in a low risk way. DNS (scoped to ESNI - not as
authentication replacement) is a bit nicer in this respect because you
don't need to manage all the clients (multi cdn), but rather just a origin
property..

tldr; imo none of this works if the origin does not have a decent anonymity
set potential. If it does, just reuse esni for that hop rather than minting
something new.

On Sat, Oct 12, 2019 at 3:19 AM Rob Sayre <sayrer@gmail.com> wrote:

> On Sat, Oct 12, 2019 at 12:11 AM Salz, Rich <rsalz@akamai.com> wrote:
>
>>
>>
>>    - How does a request of the form "username.example.com
>>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__username.example.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ujs6Lkbc_IGTiuLdcDk8syhWP1v9lNpztl9OxZuCvas&s=hBGHuzwfs66lIYRw2lkpneJu72vkeC9m5HH46EJ0i3c&e=>"
>>    get through a CDN to an Origin while leaving the SNI encrypted on the wire?
>>
>>
>>
>> The CDN needs to see the decrypted SNI.
>>
>
> Agreed.
>
>
>
>> If the CDN and origin share the ESNI keys, the CDN can just pass the
>> original ESNI value along.  If the CDN and origin do not share ESNI keys,
>> then the CDN will have to re-encrypt.  If that is an issue you haven’t
>> explained why or I missed.
>>
>
> It's definitely one approach. I am not sure which keys should be used for
> the CDN -> Origin traffic, though. I suggested sending the SNI with the
> client cert, because it seemed simpler if client certs are already being
> used (an option I recommend for CDN -> Origin traffic).
>
> EKR's Host header suggestion may also be viable, but my goal is actually
> to make some TLS-level decisions about traffic based on the SNI. EKR's
> proposal also assumes some level of Host header / SNI divergence is allowed
> by the Origin host. These policies are not clear to me. For example, I'm
> not sure what rules a Cloudflare to Google Cloud Platform link would need
> to follow (this is a common enough setup that they have an egress
> agreement).
>
>
>>
>>    - I also disagree with the argument that ESNI is pointless when “IPv6
>>    uniquely identifies the origin”.
>>
>>
>>
>> Can you explain why?
>>
>
> I agree that a unique IPv6 address would expose the fact that a CDN is
> communicating with an Origin, but I also think subdomain data could be used
> for tracking, and so the SNI should still be encrypted.
>
> thanks,
> Rob
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>