Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Nick Harper <nharper@google.com> Thu, 30 July 2020 15:18 UTC

Return-Path: <nharper@google.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 63CEF3A094F for <tls@ietfa.amsl.com>; Thu, 30 Jul 2020 08:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JlCf_k_IxZEe for <tls@ietfa.amsl.com>; Thu, 30 Jul 2020 08:18:14 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 F17863A093B for <tls@ietf.org>; Thu, 30 Jul 2020 08:18:13 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id p25so10983841oto.6 for <tls@ietf.org>; Thu, 30 Jul 2020 08:18:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qyi38KYkImN6F9WBfGDg5gZxkyWBlaoGFLeUXgHt9PI=; b=EBApBnu1y2G5B1U813auJMlaFXWPKfOOET6L/iDnHZUSF18piHjhHHBu11gxOvoM7m 6zdJxF5dI+6ecT2VRLgoA+h6JzSeDYnB6rQ+f8J86kuBrOdp7IQCUTUk5sE+/1HVuJMG 0jBOAZpK0o5tIMXXrcHCA11DQCnqj/dm4HzzOghu/D67COrmuDCvlBegh7hgWCLtHg2L ZvscYv52QX++FOGfbsi8ppUCfrlt9qU3CV996V+Td7j3EgAj7o8rtYC0TEsjRSZyurYq NMxJOCDr3HtyHW8m14UkBKsrKvHwhlOEkxOCksL9iDuJL4uwrB8Br11UsFmhNO9Iwy6c JYdA==
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=qyi38KYkImN6F9WBfGDg5gZxkyWBlaoGFLeUXgHt9PI=; b=Autgd8jGX39QP/A54oRINVIM/LNgGJWH8aBh6U8vx3M4OcUDDKar7PbGaV3/Gg+n8H +z9BNG4k5CYYawZWNovWacgg4KMsZKNkvQ9ZAn2hX9QEea4iw7N22UUWrar5hDp0gsw1 3ih7HcBa3rNJUoLHyMYXeMFdbGVqI2fJq6SmntPfb/7E2iVfRTvorazvQrom2UBbVubX +29iam1SeAXraoSaL16OIu+GT8FwKTQW3t/mLGEV7ITgtUO52oNSinW/6USXqtWQSVWJ cxzj1c3U9Rza/X4WokuMVkIac8KUcgRQHrw1lb39aH7qOtwiv2emXLxIwJKAvizphShf YiGA==
X-Gm-Message-State: AOAM532KiVZK1a8RVqYqH8xNbyXgcU7XlQ0Uk54WsBL0AB3zmYV8IwFr lrgwgP8PFoqAp/kZiayMrlPocxgxGjS5ZNcNptMegw==
X-Google-Smtp-Source: ABdhPJx/LQqtFF1X5Py7CwKadg6LFqsQcheCY4kk03iyFDsbkwzd2QKXgkOknWtiSWmvU6k6ubJHc1K51V+gq9YY4pE=
X-Received: by 2002:a05:6830:1d6c:: with SMTP id l12mr2622454oti.275.1596122292876; Thu, 30 Jul 2020 08:18:12 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0@DM6PR05MB6348.namprd05.prod.outlook.com> <CAFU7BAS=ymUPTAGB_fOSrHTG0OajV1n5M1-yOBWxvGam-a89AA@mail.gmail.com> <d9d6d8c2-3916-be28-d01f-f040a28ce361@cs.tcd.ie> <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> <CACsn0cmC=MX8p3HA4cZHnmQwoiE8BLiB1Vo__QEjzVBksvQbrw@mail.gmail.com> <E39579F4-B561-4B12-A9BF-8625B05ACA34@akamai.com> <CALZ3u+brCV_qR9Q6EhaCMSsnohwk2FnjVG=NxOnA9CaBYtW2ug@mail.gmail.com> <D4AEF5C1-7AAE-44EE-B52B-ED0FC6A47642@akamai.com> <CALZ3u+ZWdH5sfuu2KssweZLsqsUeYRCq2cae=7REszubBF5pyw@mail.gmail.com> <2D916A08-8C24-4BED-8F8A-4DD04B9B1B0F@akamai.com> <CALZ3u+bRWDZgqXiF189kwGqQDr_NVbunnenK2bF1ev7MuS6Fyw@mail.gmail.com>
In-Reply-To: <CALZ3u+bRWDZgqXiF189kwGqQDr_NVbunnenK2bF1ev7MuS6Fyw@mail.gmail.com>
From: Nick Harper <nharper@google.com>
Date: Thu, 30 Jul 2020 08:18:01 -0700
Message-ID: <CACdeXiJM83Dy+5xxEcKNhg02J1xmj=5U-GyFMGThXStAPGBOcw@mail.gmail.com>
To: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= <ximaera@gmail.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, Jen Linkova <furry13@gmail.com>, OPSEC <opsec@ietf.org>, "tls@ietf.org" <tls@ietf.org>, OpSec Chairs <opsec-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049530f05abaa2e19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JzJwFgFBxa9URZHFYlfiJCjInnU>
Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
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, 30 Jul 2020 15:18:17 -0000

On Thu, Jul 30, 2020 at 7:58 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:

> Peace,
>
> On Thu, Jul 30, 2020, 4:39 PM Salz, Rich <rsalz@akamai.com> wrote:
>
>> We have a product, site shield, that customers can use to limit the IP
>> addresses of who can reach their origin server.  Everyone else is blocked.
>> Some use that to make sure that *only* Akamai servers will talk to them,
>> and that everything else goes through us.  Is that a proxy? How is it
>> different from terminating TLS in the DMZ and sending it inside? How does
>> the client know?
>>
>
> I don't know, and this *is* the problem.
>

The point is, whatever server/device has a publicly trusted certificate for
a domain name is authoritative for that domain. That server can get the
content it serves (whether dynamic or static) from any source. TLS only
provides guarantees about the connection between the client and server. It
says nothing about whether the content served was obtained or generated in
some secure manner. That content could be sourced locally, it could be
aggregated or generated from other servers via connections over other
secure protocols that aren't TLS, it could even come from some insecure
source like transmitting an audio stream collected from an antenna
connected to the server.

I may be connecting to the service from a network I don't trust with my
> information, and I have (almost) no tool to tell me whether it is served
> from a different network via a secure connection *or* it is served from an
> edge node deployed *in the same network I don't trust*, that node being
> connected to the service through an unauthenticated channel.
>

If you're connecting to a service, at some point you have to trust that the
service operator is running it in a reasonable way. TLS only tells you that
your connection to the server is secure - it tells you nothing about the
provenance of the content served, and even if such a mechanism exists (I am
not advocating that such a thing should exist), the server can always claim
that it generated it instead of that it got it from somewhere else.

>
> Like in [1], where this unauthenticated channel is being marketed as
> "end-to-end encryption".  This approach basically defies all the end-to-end
> encryption efforts.
>
> When it comes to static content, with all the JS security implemented,
> this is mostly fine.  Dynamic content is a very different story.
>
> [1]
> https://support.cloudflare.com/hc/en-us/articles/200170416-End-to-end-HTTPS-with-Cloudflare-Part-3-SSL-options
>
> --
> Töma
>
>> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>