[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
- [tsvwg] To encrypt or no encrypt in draft-ietf-ts… Tom Herbert
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Gorry Fairhurst
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Ruediger.Geib
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Tom Herbert
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Gorry Fairhurst
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Tom Herbert
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Gorry Fairhurst
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Tom Herbert
- Re: [tsvwg] To encrypt or no encrypt in draft-iet… Joe Touch
- [tsvwg] Transports and Middleboxes (was Re: To en… Derek Fawcus
- Re: [tsvwg] Transports and Middleboxes (was Re: T… Tom Herbert
- Re: [tsvwg] Transports and Middleboxes (was Re: T… Derek Fawcus