Re: [OPSEC] [TLS] 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: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B03A095A for <opsec@ietfa.amsl.com>; Thu, 30 Jul 2020 08:18:15 -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=ham 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 zeRLKGrXG5Xz for <opsec@ietfa.amsl.com>; Thu, 30 Jul 2020 08:18:14 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 017C83A094E for <opsec@ietf.org>; Thu, 30 Jul 2020 08:18:13 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id l26so3796419otj.4 for <opsec@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=N63wS15SqDmAlw4Pi4x5ZuS0dYYTD3trtqoi8nqFtuMNpe1e4RqcokiXM8ZADOQap6 +rBuunpQy4RNqeRfDaDbnW7wG4WnbUU+M6D8lAFG13GJ+QDgElymOE6tbZXCycqL0Q6P KcALdvQ0WnRyaz8LSZePBjLXAQj2c+swUmn5JWDfpRbP3ZMiTiQH+dmMSBFms499sLk8 mqzSaXyYjtPvh8pS5USvzjoMheA3c5aw/ekYNZU61PEHBREgFfAAUHv+FCZbZu6H+OcJ CkLBYUgsHL7CBtc23+T3oAJh4OUiwof1ZH6bkkRfqWsiM9+5JuSP3QoDOXwmlxnQMHYw Bn0A==
X-Gm-Message-State: AOAM5306d1u27MitOa21pZUoBe/IY+qW4Xawwb5t8wGIiFQiWji3XDIL x1honzhwLI97mtEXzNQT8QdcXDa8CjxeMbtMt+GjCQ==
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/opsec/NcKZLXF134bZ5uqqceZbuOTH9s8>
Subject: Re: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 15:18:16 -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
>