[tsvwg] To encrypt or no encrypt in draft-ietf-tsvwg-transport-encrypt-01

Tom Herbert <tom@herbertland.com> Tue, 20 November 2018 19:03 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5267D130DCD for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2018 11:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 eZ_B7kM5EH6f for <tsvwg@ietfa.amsl.com>; Tue, 20 Nov 2018 11:03:02 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 59F13130DC6 for <tsvwg@ietf.org>; Tue, 20 Nov 2018 11:03:02 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id 189so3466385qkj.8 for <tsvwg@ietf.org>; Tue, 20 Nov 2018 11:03:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=miWJyq61ZR3RSsrXwU4yna0LA7GupDoQqNOVSf+dvS4=; b=l7WkJGRaE1AVyIlPjUoCMePvFTdueYncVpn7eS+8caQQE998tlgUU8lfsQyD+Y2isv l91DF6WvqgTE6mo1ct7v7QDNRCjRgfBCu2et0vT4Kpw7Qrsog0rGmJBM7SrPQbVEwXzn 6vMGbqfxKvjyELgBar6HzKrxMtHpylRUeZt7piiyvpchUovX03WCARwEAHe2KdX2q42n vPRRupLN1M/pSxdTrDMy3oWgNin9T2fFbBRGKQgkJb9Up+bxtWvDyagZrvrRn9dSFQ8O W0+y8s6H5mGTvjDb2IISrrR7+doRr5iZPx4EyU9Zk3MWO32PxkheVe7Y6WNTz/wqAsWw k59w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=miWJyq61ZR3RSsrXwU4yna0LA7GupDoQqNOVSf+dvS4=; b=GZ7YdVnzCKRXtTyRD+tLLgLV+zVlZXRsapSnJDUA86j/JT/8dnyvmm4JFkjy1OfgR3 vtqk1zEMySCB3ymoqRqkz621vR9whJrvbR0OR7pIqI6GQw1wIBaSzFMzBSRkQY86qYzk ZVLz6VfVLg/yW2oHN9QGCcsfdgRy5eHliKmDT93AhwFrBBACTVMXTyR4/8IsVqC3C13Y DGYuiSytsjQk8RKiU2PWR6p7febjRi1nR19NjhLPcuB6dU8FPGjr/3g7A3/ljJJu4ssW qxjhdBw0Qcjj+YQt9Aspat7M9MaypjkAfY+GXmhqCm7X1EwumQ58lLqcXW+1i6dxCJIU tXwQ==
X-Gm-Message-State: AA+aEWZH9900B6PJ7CE3yvUdNIhT+MYuXcjcWW0ApkyYjw10j/Wj/KGz LCve9v//1Gz+ppoVF2qHvoSu1qEugCPjOpZmsW6DtqWWl3E=
X-Google-Smtp-Source: AFSGD/UcrmHBZ5BcQcb0M2kQgkfi7YFqwk8sCgChiIOOklV3WtaXxb09y55jdK6+AXVmKplFnZ8aBiQW7WpsKe3y7Oc=
X-Received: by 2002:a37:7885:: with SMTP id t127mr2961375qkc.323.1542740581094; Tue, 20 Nov 2018 11:03:01 -0800 (PST)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 20 Nov 2018 11:02:50 -0800
Message-ID: <CALx6S37xamS9akt6vWR1vgUaAMbMqbw+1nYyKXPvTvYF1s0vSQ@mail.gmail.com>
To: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vzd_UJtJX0UUuS0yH6wej6LOiNs>
Subject: [tsvwg] To encrypt or no encrypt in draft-ietf-tsvwg-transport-encrypt-01
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2018 19:03:04 -0000

Hello, I have a few comments on the the draft relating considering the
trade offs of encrypting the transport header..

My general comment is that IMO the draft is too biased towards not
encrypting transport headers. The benefits of encrypting the transport
header aren't fully explored. In particular, the benefits of encrypted
the transport header should be in its own section and elaborated to
provide a balanced comparison with section 6. There are several
benefits that I think are missing in the current description also,
like the fact that encryption deters intermediate nodes from
maintaining transport state, authentication prevents intermediate
nodes from changing transport header, the end to end model is upheld.
saving the costs of DPI into the transport layer in hardware.

I think there should more discussion around the use of extension
headers as the current draft too easily dismisses them as not being
viable. From a protocol perspective, extension headers clearly are a
superior solution as they are a protocol agnostic means to let hosts
signal the network. For instance the draft talks a lot about
measurement, and in fact there are now proposed extension headers to
provide that sort of thing.

Also, both the benefits and implications need to be better quantified
if a protocol developer is considering the trade offs. For instance,
the draft says:

"Some Internet users have valued the ability to protect identity, user
location, and defend against traffic analysis"

I would like to the meet the Internet user that is not concerned about
their privacy and security! I believe this applies to all users and
the need for security and privacy is ubiquitous especially as the
Internet evolves to support "life critical" applications.

To contrast, the draft also says:

"Independent observation by multiple actors is important for
scientific analysis."

"Important" is relative term that's used in several places in the
draft in describing the benefits of not encrypting transport header. I
don't know why this is important, or at least why this could be more
important than something like user security. Neither is it clear that
the need scientific for scientific analysis creates protocol
requirements that are applicable across the whole Internet.

To me, it's clear what the costs are in not securing transport header
(loss of security, privacy, and increased likelihood of protocol
ossification), but it's not clear what the what the tangible benefits
are to the users if the transport header is purposely exposed to the
network? Will transport protocols become more efficient somehow? Is
this actually stronger security somehow? Is measurement based on
transport header information so understood and specified that it's
used every where and all user benefits somehow?

Tom