Re: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Phillip Hallam-Baker <phill@hallambaker.com> Fri, 08 November 2019 17:27 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920551208E3; Fri, 8 Nov 2019 09:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 MKpCiReyyiSf; Fri, 8 Nov 2019 09:27:58 -0800 (PST)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 3AFE112088D; Fri, 8 Nov 2019 09:27:58 -0800 (PST)
Received: by mail-oi1-f179.google.com with SMTP id l202so5940301oig.1; Fri, 08 Nov 2019 09:27:58 -0800 (PST)
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=o0t3sLXi0j3TVGQjYlXTjdT10qLpwl0urho7VVfPwwo=; b=FRN6gExKYNvgHBILlyH95oxgPjNlJJfXllEAELojKXpvNiveVT6+w8cfXkeZP9bBWw NK6XRpSgGT1IiP8+FT3MI7iJEzW2Q6CnRa7y8xS+UB9gsTByeT4G2muCeRdKgHGQ5Yfh SR3EQUeIud/WftSnIj8DU/AIO+RT6ObSZWbvaXYU6TuoFDuLhsvOIYqvGPxfmUQ+iG1V Tl/nkaZM9Bh28gZLmYTrcikyXNWKCpRjlQ9LcfF4VmslargsLXDEb5gft+vElx72vNLD /wQqzmRb9WjHaTbQODIaUHMg5Gy15BcFAIUp4cyDy861GQLZARvGU9hE+1EZYvecXh7Z Q2cg==
X-Gm-Message-State: APjAAAXTTp0sEAoRn48KXXKdRIUXaubTtUfJGnm0kbPfdc5IPCHKT3vc 6BeCImU4mZcSFQZpGvywGJ8UV/0j4n7c8/dCJNDGKw==
X-Google-Smtp-Source: APXvYqw4MUjB4NNVIB2CcbV8oSDfL6RmJkEPRCt8TYk5Y59iqazzv1exttYwLmKAsjeaaL4T8iqgVar6PKQi1UZkbrA=
X-Received: by 2002:aca:5058:: with SMTP id e85mr10972843oib.100.1573234077175; Fri, 08 Nov 2019 09:27:57 -0800 (PST)
MIME-Version: 1.0
References: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com>
In-Reply-To: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 08 Nov 2019 12:27:47 -0500
Message-ID: <CAMm+Lwg2SxwKoqS3wDe6X3X-2W5i-eR76094GqzERM0OxWOR6w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051954b0596d91a31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/5EcU052Pxo2adFP6AHcs6t9Rzmo>
Subject: Re: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2019 17:28:05 -0000
I have a slightly different perspective on this. To me, a Web Server is just another type of middle-box. Specifically, it is a middle-box between the content provider and the content-consumer. And those are the ends I wish to achieve end-to-end security between. Transport security is useful but that has been our only hammer for 25 years now. Data in transport is a solved problem, the breaches occur in data at rest. And as a famous Snowden breach slide shows: 'TLS added and removed here'. This is not to say anyone made an error in design. What was possible when we were looking at this in 1993 was considerably less than what we can do today. We were using export grade encryption for a start. And we could barely use one layer of encryption. And so we adopted TLS as a Golidlocks solution that provided most of the network layer security we need and most of the application layer security. I think we need to change our perspective somewhat because we need TLS and Data at rest security (DARS) and we do need certain types of metering. But in the network, not in the inter-network. Alice uploads content to Carol's Cloud, Bob reads it with his browser. There are three (potentially) separate networks here. Alice's local network Bob's local network Carol's local network Alice, Bob and Carol might all see the need to do certain types of monitoring. But the principle of least privilege should apply in each case. Carol's need to monitor her network is strictly limited to Carol's needs. In addition, we have the inter-network which as Einer Stefferud used to remind us, isn't a network, it is a network of networks. And so the communication graph is: Alice <-> Internet <-> Carol <-> Internet <-> Bob And that matters, because the primary concerns we are addressing in TLS are the ones raised by that 'Internet' hop. The advantage of IPSEC over TLS is that it allows us a much more closely targeted solution that locks down the Internet hop without affecting anything else. The disadvantages of IPSEC... So what I see happening at the moment is QUIC/TLS morphing into what IPSEC was originally trying to do. Which is fine except that as EKR is point out, this is compromising us at the upper layers. Which is where Shen and SHTTP were originally intended to work. I am actually planning to use three layers of encryption for Mesh services Transport - (TLS) to provide traffic analysis resistance. Presentation - (DARE) to authenticate client/server interactions Data - To protect data at rest The concern that Transport Layer Security inevitably creates is that any scheme which provides any traction against traffic analysis is going to make monitoring difficult because it is traffic analysis. In summary, there is no way to square this circle because what distinguishes traffic analysis attack from monitoring is intent and machines can't tell the intent. And so if people want to expose information at the lower layers, they are going to need to think about additional layers of crypto being added at the top.
- [saag] Comments on draft-ietf-tsvwg-transport-enc… Eric Rescorla
- Re: [saag] Comments on draft-ietf-tsvwg-transport… Bernard Aboba
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Joe Touch
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Christopher Wood
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Frode Kileng
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Stephen Farrell
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [saag] Comments on draft-ietf-tsvwg-transport… Phillip Hallam-Baker
- Re: [saag] Comments on draft-ietf-tsvwg-transport… Phillip Hallam-Baker
- Re: [saag] Comments on draft-ietf-tsvwg-transport… Michael Richardson
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-t… Peter Gutmann