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

Christian Huitema <huitema@huitema.net> Mon, 04 November 2019 16:30 UTC

Return-Path: <huitema@huitema.net>
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 48D1812096B for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 08:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Z5v1mk9FY7cW for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 08:30:11 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAC5120AAB for <tsvwg@ietf.org>; Mon, 4 Nov 2019 08:30:10 -0800 (PST)
Received: from xse392.mail2web.com ([66.113.197.138] helo=xse.mail2web.com) by mx147.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iRfEj-0004ht-IN for tsvwg@ietf.org; Mon, 04 Nov 2019 17:30:00 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 476JCP3231z1kmD for <tsvwg@ietf.org>; Mon, 4 Nov 2019 08:29:05 -0800 (PST)
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iRfE1-0004r3-9X for tsvwg@ietf.org; Mon, 04 Nov 2019 08:29:05 -0800
Received: (qmail 6719 invoked from network); 4 Nov 2019 16:29:04 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.152]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <saag@ietf.org>; 4 Nov 2019 16:29:04 -0000
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Eric Rescorla <ekr@rtfm.com>
Cc: Tom Herbert <tom@herbertland.com>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
References: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com> <CALx6S35bSAa_zq=HsF-3e9qC-vRNFRu6dn+O4ak4Hi+c=Tmz5A@mail.gmail.com> <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> <CABcZeBPfT=B+fOXAkPuoEQQHAtJrefXSgnjOpPC7-4zC_myRsA@mail.gmail.com> <D36061F0-F872-4054-ACF0-C9A88FCEC572@ericsson.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net>
Date: Mon, 4 Nov 2019 08:29:04 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <D36061F0-F872-4054-ACF0-C9A88FCEC572@ericsson.com>
Content-Type: multipart/alternative; boundary="------------81A18ADC0E6C560E0D73ADFC"
Content-Language: en-US
X-Originating-IP: 66.113.197.138
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDAxcDYLQWPWOwvKJpm+ErX5j9 EvBvwu01uVCaGVBWGqtsJbqiM7gVQGSitF9PqLWj2rBNMmEsKEibQwSU1xBeOHButNDpi1WUXRkr He1vFsZaZad0VL/QynhFAlbT36L8uicyKhzyGfAlDuzBR8AtPgZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwB+XPdEXquZ7 t0MUOMrNUB2ISKeE2kBFydVonbwS2Hp77QqrdHSfyP8MwLHqRn/ce283/P/j910AEtgqSA/ogRHv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqbq1iQQhopQxqA dW22RV24UGyi5u9gyIeaEyGcULdX9dQ84QG89JN6MvpNdzLqW7pf6ZFDqz0I1GSQ4kRGWg2/HHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+0TslPr9o/YxfJh+1JYwZn808QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/meD8PXPSKSdxubF4zgzPJ8p70j0>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
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: Mon, 04 Nov 2019 16:30:14 -0000

On 11/4/2019 6:59 AM, Mirja Kuehlewind wrote:
> ...
>
> Well, we put a single, optional, bit in the header and everything else
> we could figure out how to encrypt encrypted. It's true that
> encryption has a cost to the design of the protocol and to the
> endpoint implementations and we've been trying to balance that cost
> against the value, but that's not because the group isn't trying to
> encrypt as much as possible.
>
>  
>
> [MK]I don’t think we need to nit-pick here but I think "encrypt all
> the things" and “encrypt as much as possible” is not the same,
> especially as “possible” is something to argue about when it comes to
> the question of how much you are willing to pay. However, I don’t
> think we need to discuss this in details here, just wanted to say that
> I don’t think the situation is a simple as you have stated and I don’t
> think there is consensus for a simple "encrypt all the things".
>
>  
>
> I certainly realize that there are people who are sad about this -- as
> you rightly point out reflected in this draft –
>
>  
>
> [MK] I don’t think people are sad about increasing amount of
> encryption. But when we change things we also need to have a
> discussion of the implication of this change and cannot just close our
> eyes. As I said in some cases we might be happy about things that
> hopefully just go away, in other cases it may actually have more
> severe impact of the viability of the Internet as a interconnected
> network that is operated by different entities.
>
>  
>
> but I believe they are in the rough, at least of the community of
> people actively designing and deploying new protocols.
>
>  
>
> [MK] I don’t believe this. Otherwise I wondering why we had such a
> lengthy discussion for more than a year in the QUIC working group.
>
We had that discussion, and there were indeed two opposing ideas: on one
hand, expose some information to the path for network management
purpose; on the other hand avoid exposing information to prevent
ossification and interference, and to avoid privacy issues. Only some
the "network management" arguments actually gained some traction:
enabling measurements of network latency, enabling measurement of data
rates, and enabling measurement of packet losses. One of the problem
with the current draft is that it does not distinguish between these
"common ground" objectives and a slew of other "network management"
practices, such as discriminating between flows or interfering with
transport protocols. It also mixes in transport protocol debugging,
which is a different subject.

Just because we have some consensus on the legitimacy of measuring
latency, data rates and packet losses does not mean that we want to
incorporate support in the transport protocol. We quickly realize that
there is nothing particular needed for measuring data rates, beside
separating flows by five tuples and counting packets. We struggled with
the privacy implications of measuring latency, because doing so may
enable triangulation and does enable the detection of proxies. We also
failed to achieve consensus on a specific way to enable packet loss
measurement, because we could not reach consensus on a specific algorithm.

The QUIC working group converged on enabling latency measurements on a
fraction of the flow. It appears that measuring a relatively small
fraction of the flows is sufficient to gather statistically significant
measurements of latency. Ensuring that a sufficient fraction of the
flows is not measurable enables privacy protection for sensitive flows
that need to hide usage of proxies.

The draft does not include this kind of discussions.

>  
>
> Do you see any plausible situation in which a new transport protocol
> isn't largely encrypted?
>
>  
>
> [MK] That’s not the intention here. But we also need to consider ways
> to interact with the network where this brings benefit to both the
> network and the performance of the end-to-end traffic. There are
> situation where this is the case. And I don’t think one makes sense
> without the other.
>

You seem to be arguing for something like "performance enhancing
proxies". End-to-end encryption is indeed a way to opt out of such
proxying. Measurements so far indicate that opting out has very little
impact on actual performance, and that whatever impact there is could be
reduced by improvements in end-to-end algorithms. In fact, in many
cases, end to end performance is better without such proxies. But the
real reason for the opposition to the concept is ossification. Enabling
such proxies would quickly ossify the new transports, and a such there
is a strong consensus in the end-to-end transport designers to use
encryption and prevent interference by such devices.

This does not mean that network level deployment have no role in the
future. I could see for example tunnels deployed that use FEC or local
retransmission to mask the poor performance of a particular subnet. Or I
could see end-to-end devices opting into some kinds of application level
caching services in order to improve performance. But the draft should
be clear: transport protocols do not have to enable interference with
the transport bits.

My take is that this draft should not be published as is. It should be
rewritten to actually reflect the consensus of the transport area, which
has to reflect in particular the work in the QUIC working group.

-- Christian Huitema