Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

Martin Duke <martin.h.duke@gmail.com> Thu, 27 February 2020 21:26 UTC

Return-Path: <martin.h.duke@gmail.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 6195B3A0C4E for <tsvwg@ietfa.amsl.com>; Thu, 27 Feb 2020 13:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AJm7a4FMvjvf for <tsvwg@ietfa.amsl.com>; Thu, 27 Feb 2020 13:26:33 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 58EA53A0C4A for <tsvwg@ietf.org>; Thu, 27 Feb 2020 13:26:33 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id a5so1067214wmb.0 for <tsvwg@ietf.org>; Thu, 27 Feb 2020 13:26:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7a98gUozp9drcnqQPmOwEFvoAHJCaacbpZYeKwAe8Xc=; b=mreWMadK3cxt2+V4tBeUtrpBWw641Bf49bIe61wE2Wlk9/96WRlUHwx2e87jljLgcu gqyqz/vi1qtPmZjAu+nIvPj3A/auW1ZLtd85HafUgjH0VN1Sm4Y8hAuQQMARx9XTRATs HHw9hYuRHXOOWpA8y8KpLq9A8ozlxBi1QEIl/Djb97aIPrCkaZc0flIYg+HBBFrvybNR 4k0gvtf6uNdM6cv6tkz9PPLiS6UIZeinH4e8hgoqEiXUiTNky8wnIHcC5JRsUPp+PUXF lahVnQ/AvStzJWLqtapRo8UKh53cqqKOTPv7TZbpH2XGKSTZ1otnJqz4WzEvuA9Fsg7v Gtzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7a98gUozp9drcnqQPmOwEFvoAHJCaacbpZYeKwAe8Xc=; b=fClF77LvCHG2yIiWuZ1e9Cd5kHUJqaNLyUlCWkaYHF6GqpBdDBiztpAIx4TpiKi/Rm ER2/ZgVWX3f5qclxdz6YcWgi4+lcrX9oQMtLfMcgMAd7dDuCzwsllmuG1HQBfiytgXNC 85JQ6vUV9jPNJjXm2mLWTdJzm1+s+Zp3ymtKjsu9UP9CDfWafvk1iItoLwv54KhyKU+l zBza0I0HIk1rQGpiu2wZep0nG7EyUgxrh1Qr4jvebHn3uCX8TALz9QV+GfhhLV50GDFG BY5D+8+0OR6C+H0iu8vgSSai9+s6HX2rv9RE66G8adT+xKPIemfFM4l/6JH/iqRfFiiS YKvA==
X-Gm-Message-State: APjAAAUrXMBmJi/ofThhiluRy5TPcwvM2i7wHTNeje+EcDaH5sKgHD64 rT2znn1T32OsuK1ahuWogjf2Bg7juYw0QA1LUDI=
X-Google-Smtp-Source: APXvYqx9gaUjO5HDHXXb4tIxtzczI9X28bODfaUU93FC6ScWAE9sJxZ5qhv6FPZzA8GPHygZA5dmZfZK0aBP3VRJheg=
X-Received: by 2002:a1c:7215:: with SMTP id n21mr779033wmc.154.1582838791679; Thu, 27 Feb 2020 13:26:31 -0800 (PST)
MIME-Version: 1.0
References: <158279435525.6196.11790581771168846041.idtracker@ietfa.amsl.com> <3c7f9e3c-d4f6-b002-5e16-6611d654c8eb@erg.abdn.ac.uk> <CAPDSy+5e0HYhBJdQm-ZhBcqmqwKGkpaKU8t_9R2_P=nAOs9s2w@mail.gmail.com> <1a3178e6-cca4-ac62-d21e-1ce1e00d9ba5@erg.abdn.ac.uk> <CAKKJt-fgZO9rcY1q9FHd6mEm+_QaARfAQJbgAV9NmxX+Odo3_A@mail.gmail.com>
In-Reply-To: <CAKKJt-fgZO9rcY1q9FHd6mEm+_QaARfAQJbgAV9NmxX+Odo3_A@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 27 Feb 2020 13:26:20 -0800
Message-ID: <CAM4esxTezK1KHO-B6TaH4tPrj+qtdXC8n4QQVpGu32Q4_scFEw@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ea375d059f955f6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/yDLXpToDqd1Sem1X5zik3URSTKs>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
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: Thu, 27 Feb 2020 21:26:35 -0000

One thing that came out of the spin bit discussion is that some transport
protocol experts honestly do not understand how this information is used
constructively in the network. That may be why the initial tone may have
been a little unbalanced.

To answer your question, David, I think your takeaway as a transport
designer is to understand what you are sacrificing when you encrypt
transport headers, and consider exposing specific items if the benefits
would suit the use case. Other transport designers (though none that I
actually know) might benefit from an explanation on why transport
encryption is worth doing.

Martin

On Thu, Feb 27, 2020 at 12:25 PM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Speaking as a non-area director (so, I don't have a hat to remove) ...
>
> On Thu, Feb 27, 2020 at 1:18 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> wrote:
>
>> We discussed the scope a lot at the start, and the advice I received was
>> that this is not the document to tell people about what they have to do.
>>
>> I think the decisions about whether to encrypt all transport fields or
>> some or none isn't something I saw huge consensus upon. I did see many
>> strong arguments, but what I heard often depended on which working group
>> was speaking and the background of people involved. Had I asked a different
>> question, e.g. do you think Privacy is important I would have got a
>> different answer (we do have a BCP that notes that).
>>
>> The AD advice I recall at the time we asked to work on this, correct me
>> Spencer if I am wrong, was to not attempt a BCP until the WG could first
>> publish an informational document. This is that document. The purpose then,
>> as I see, is to examine where we have arrived. Had we had a document like
>> this, other discussions such as how to manage QUIC, whether PLUS could be
>> useful, etc could have been more informed and focussed.
>>
> I believe I was the AD who gave this advice, and Gorry is recounting that
> story the way I remember it.
>
> From my perspective, we had just been through a great deal of kerfluffling
> with MARNEW(1), SPUD(2), ACCORD(3), PLUS(4), and "Effects of Pervasive
> Encryption on Operators"(5), all of which had various levels of
> food-flinging, and all of which had various levels of assertions about
> whether operators needed to manage transport protocols, with little
> agreement on ground truths about what was, and was not, possible to manage
> when looking at existing transport protocols.
>
> I wasn't seeing anything that led me to expect that to change before the
> earth fell into the sun, and the volume level was increasing (watching
> Meetecho for the PLUS BOF would drive anyone to drink, even today). So I
> encouraged Gorry to focus on ground truths, so that we would be able to
> actually have discussions about what might go into a BCP for protocol
> designers (as David reasonably points out, that would be great), and/or a
> BCP for network operators.
>
> One can debate whether I did the right thing (but that wasn't appealed,
> and I wasn't recalled). I'd defer to the current ADs (both now and after
> IETF 107) on what to do next, but I thought it would be useful to provide
> background on how TSVWG got here.
>
> Best of luck to Magnus, Mirja, and Martin, of course. And you don't HAVE
> to have a name that starts with the letter "M" to stand as a nominee for
> TSV AD this coming Nomcom cycle :-)
>
> Best,
>
> Spencer
>
> (1) https://datatracker.ietf.org/doc/rfc8462/
> (2) https://datatracker.ietf.org/doc/minutes-92-spud/
> (3) https://www.ietf.org/proceedings/95/minutes/minutes-95-accord
> (4) https://datatracker.ietf.org/doc/minutes-96-plus/
> (5) https://datatracker.ietf.org/doc/rfc8404/
>