Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Phillip Hallam-Baker <> Fri, 08 November 2019 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 920551208E3; Fri, 8 Nov 2019 09:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MKpCiReyyiSf; Fri, 8 Nov 2019 09:27:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AFE112088D; Fri, 8 Nov 2019 09:27:58 -0800 (PST)
Received: by 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;; 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: <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Fri, 8 Nov 2019 12:27:47 -0500
Message-ID: <>
To: Eric Rescorla <>
Cc: tsvwg IETF list <>, IETF SAAG <>
Content-Type: multipart/alternative; boundary="00000000000051954b0596d91a31"
Archived-At: <>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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.