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

Tom Herbert <> Thu, 07 November 2019 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E1D01209D0 for <>; Thu, 7 Nov 2019 08:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3dv9p4pDDyfm for <>; Thu, 7 Nov 2019 08:16:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C31A1209AF for <>; Thu, 7 Nov 2019 08:16:14 -0800 (PST)
Received: by with SMTP id m13so2349096edv.9 for <>; Thu, 07 Nov 2019 08:16:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=alSnbw1yE+TfgP/karC+3lzh/7xuva8JEnQInYPiaBw=; b=zARQhWtoM2HfpFYqtvjITfabOJgfWONKu5yzxI2JmN/InRZovOTpkfL1rpz2/pl8kJ /m5cdsT3TKa5HOpKhNNNPGTjeTm1dPiVdk1GE27KQmnO2IeheAjKKen+CkmCzQOU48d8 qyZIWCv5c0zdkpWyaq7njGCZaBWS6hMy8pO4T652xmqLfoJUAWP8ZqtJE3djfzHsWHq8 ILsNPeYk1mf4yuKebP0CjAKL8TIxnSkcqiVxNamT7cvpr+uunlks81rCe1g05Rdv0ZWI uIGS9MVfaqu7Yv4WABCfy0SBXdPEOMd5G5WOLLeiaFW+b2PMM0oE/7LoHhTfdHgoqCn8 8KNQ==
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=alSnbw1yE+TfgP/karC+3lzh/7xuva8JEnQInYPiaBw=; b=WYn8yn/mUCiaZFut3pHeSaEO7Q9aAfusQUGZJAjw7Vgh+1i60n6XZ8jPvqFnIpk3DM LqcJKkiI5TsMuNlO5rRxJPWYfc3/F0268z4ibOYNy0swLJAOCu0l3hkVeaYNCiBqWfCd tUGfsRKK/Vt1pl9QEBspi/38Vyfvmi1OxMUkmAxqeJtTVUIZlLr+o3jw7rTuotGAoa2x 4Y8Boyo/gPqQV2K/0JO2NK6+eQS+v07PtwWVnUugcf3XHNXy3urjpjYBfMn9ToEpT74/ MyNkkBefvRCn4ZGblJ23bKkXZ2c30PmkFqJDckyfYehNqOx2/7ENtZn/RbwwSuc2pDlt iiBw==
X-Gm-Message-State: APjAAAVFql/LtgHXmTY+yJ2FqKRgtZdNqJxz7K60jv/cXTP+HYGaXu8w Lm8fs/vj6QO++6+3jrYMRdj98ECXrkdDxNl0eTbj0g==
X-Google-Smtp-Source: APXvYqwFAAOawdTCPtspL0WOwJT7I1ul2HZ+3Sg8N98LJ3a4oFfG9ad+GkQ+ivZoZ1jkACr0m0cO09Mkr24wkexKmG0=
X-Received: by 2002:a17:907:1114:: with SMTP id qu20mr3967787ejb.42.1573143372914; Thu, 07 Nov 2019 08:16:12 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 7 Nov 2019 08:16:01 -0800
Message-ID: <>
To: Peter Gutmann <>
Cc: Stephen Farrell <>, David Schinazi <>, Joe Touch <>, "" <>, Mirja Kuehlewind <>, tsvwg IETF list <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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: Thu, 07 Nov 2019 16:16:20 -0000

On Wed, Nov 6, 2019 at 10:51 PM Peter Gutmann <> wrote:
> Stephen Farrell <> writes:
> >In addition, the document is missing any real description of the harmful ways
> >in which cleartext headers are being (ab)used today.
> That's actually something that's missing in general, not specifically in this
> document.  Header encryption seems to be taken as an article of faith, we must
> do this because it's something we must do, and yet from long experience with
> the two protocols that do header encryption (or at least protection), IPsec
> and SSH, for the former all it's produced is endless and ongoing headaches for
> devices that need to forward/route/manage IPsec traffic, and for the latter
> all it's produced is a string of security vulnerabilities.
> So what's the sound technical - not religious - argument for header
> encryption?  Calling it "abuse" is a purely subjective statement, one person's
> abuse is another's essential functionality.  One big example of this DNS
> manipulation to implement captive portals, which the DNSSEC folks I've talked
> to regard as anathema but without which maybe 90% [figure totally invented] of
> public WiFi won't work.  So to the DNSSEC fans it's abuse, to pretty much
> everyone else except a few DNSSEC fans it's fine because they want public WiFi
> to work for them.
> In particular for header encryption there have been at least two dozen papers
> published, and many commercial products created, that bypass encryption to do
> fairly extensive traffic analysis *of encrypted traffic*, encrypted headers or
> no.  So on the one hand we've got real-world experience with two protocols
> that do header encryption/protection which has yielded endless problems
> (IPsec) and security vulns (SSH), and on the other hand we've got what seems
> to be a faith-based belief in something that numerous academic papers have
> shown doesn't provide the service it claims to.

The problems of protocol ossification and middleboxes meddling in E2E
protocols has been discussed at length in IETF in various contexts.
This is a real problem. It is well known that encryption of as much as
the packet as possible is one mitigation to present protocol
ossification. For instance, this was exactly the rationale in QUIC to
encrypt the whole transport layer.

On the other hand, the draft provides most anecdotal information that
plaintext headers are useful. For instance, there's a lot of
discussion about network operations. It is conceivable that this
unencrypted headers might help network operators, but then that raises
some obvious questions. Do all operators look into transport layer? Do
all network operator require the same information from the transport
layer header? If they do, what is the EXACT set of transport layer
information they need? Do they all support the same transport layer
protocols? What if we start using a new transport layer protocol from
hosts, are we out of luck because that protocol is not on the
"approved list"?

If there were answers to such questions then real requirements both on
the host side and network side could be articulated and there might be
a basis for a meaningful discussion, but in lieu of that all we are
left with is vague guidance for the transport layer protocol designer
that they should consider how middleboxes _might_ to meddle in the


> Where's the technical argument for header encryption, backed by actual
> research showing that it's effective, and that the benefits outweigh the
> disadvantages?
> Peter.