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

Eric Rescorla <ekr@rtfm.com> Mon, 16 March 2020 15:34 UTC

Return-Path: <ekr@rtfm.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 AC1513A0A59 for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 08:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-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 tnah8auHN1sr for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 08:34:19 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 8680F3A0A65 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 08:34:18 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id r24so19205180ljd.4 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 08:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5lkhxQl0NqPrkhp8u/iQF4w2K68U54+IwEnLuAcjheI=; b=RzLeF8XKz12w6PEKrxQsvVoPWLPF0dFaDLiPKan6QDm0YJJiqwtm/E3RGQPkl/WUPy SirJhlVdydOuo7zKXZSZ8hf3o1TzSpdVyvpx6+lYzkNDbD1X42gd4x6obME7uRsM3W2b /Ela5Tqh4gNQsuknKcxzoKux6QJJGuwSLmWR74LE5VZY/IuXtHbh1xrL8UP4IY5X9de7 IejCgaMgkiwIuSopaQiKpWrQQCi0JiZfoKw4JqFwztc0es9pQWKPQhuU0VkZsyuLSnBG BKTU+afDydisvfI0CxTT0Ks6wLY84bhdpQ1PXEeiAwjLa5EW5ABEXqvqOq+bi4E8vWxo rceg==
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=5lkhxQl0NqPrkhp8u/iQF4w2K68U54+IwEnLuAcjheI=; b=EYJAmYR+Y79Fpu1oOrYIOHWO6zDl51X4l2lBWxyPVCazFITr809Mm081/pJvhCZEBy bIuc9alU58dMbm2JKud+t/jhaznK45w5W5p1V15PIxiVRlMyYhtdaxfeQv4MDUOWB8m3 r3a8xJtK1OrHVrxnGNZ0OXMWApW/gwa3dGHwlBIaZvl2nILqBdMCJB/suLir0X8Ad8AC YuzbugJBnVViNLt5DMg5MWURjHJ/nHxyf6+fA12UoQjA9t/G9UawBJ1yGqLU4GljYNcT MmnCWQKbd7/nF4iHFHfaAmyiPMPZOfs8C/5ot/CwId0kSeumyTkzw3UTbhOYC2CAEUyW Hu/g==
X-Gm-Message-State: ANhLgQ1raLdBvVXoD7Zu/UaaO6WETIk11OOix6Kfq0DKs5xcJv0oOci+ AwGHcq26UZOHYXDB+yjf1KmO/UXNcuEqXEd2jamUQYX3b7DiQQ==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vv/1jSAgH9anycpQ2WxyZZtEc9f2h78reNrjBLv?= =?utf-8?q?wDr9z25mX8/aJbBsHPxtrLRvXLgOVR1BJxjupfaJ9jegfMU=3D?=
X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr16609411ljn.162.1584372856728; Mon, 16 Mar 2020 08:34:16 -0700 (PDT)
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> <CABcZeBOdDU0zQ+ZNQqu1vDWxQuLUzGqi9MMXPDUs-izZEgVQsg@mail.gmail.com> <CAM4esxTA9mheGALtp4zKKYVV7wNUfhp-0pdt3C62G=tkTQhaDQ@mail.gmail.com> <CABcZeBOPxLWfT3Un=+_DQoaP5Zf0_COJ=cBLsVwMZHGgu5BOHw@mail.gmail.com> <CAM4esxQMPEemk6db6hGTLdt4xetHRhV=9DD51sjd3ppn+SffEw@mail.gmail.com> <CABcZeBMR61e0CsdCg5y8PkQskm0tbR-+BKXWQghavGKBN6PyHA@mail.gmail.com> <abdc3cc8-5948-1b5d-516d-6d736b7ecda2@erg.abdn.ac.uk> <CABcZeBNVZp_H+02D_B-bg56_==W_9feZ_Z91Oc5R+6P4giftnA@mail.gmail.com> <c6b40d15-244b-5f63-8aed-e3eca3373638@erg.abdn.ac.uk>
In-Reply-To: <c6b40d15-244b-5f63-8aed-e3eca3373638@erg.abdn.ac.uk>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 16 Mar 2020 08:33:40 -0700
Message-ID: <CABcZeBOqEymmY3JjX-+MHSUuKrLtvqSxxJ4DfspTnS5+uLc3Dg@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Martin Duke <martin.h.duke@gmail.com>, David Schinazi <dschinazi.ietf@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000513fc705a0fa8d20"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Y16zdcI9CEgUpUtgG3cb7ZPZeCY>
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: Mon, 16 Mar 2020 15:34:21 -0000

On Mon, Mar 16, 2020 at 7:51 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
wrote:

>
> On 16/03/2020 13:06, Eric Rescorla wrote:
>
>
>
> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> wrote:
>
>> Ekr,
>> On 15/03/2020 13:19, Eric Rescorla wrote:
>>
>> Let me try to expand my point a bit.
>>
>> Longstanding practice is for entities in the middle of the network to
>> use signals that were intended for the endpoint for their own
>> purposes.  With QUIC (and a lesser extent SCTP/DTLS), those signals
>> are being encrypted and thus unavailable to those non-endpoint
>> entities; this draft is mostly devoted to documenting the negative
>> impact of that change on the operations of those entities.
>>
>> I disagree that this is "documenting the negative impact of that change".
>>
>> The draft is about how this protocol information has and is being used.
>> As long as I can remember, there has been devices that utilise some of this
>> information, at the edge of an enterprise there is often at least one
>> device with this role; within a managed network there are devices; etc. If
>> the trend to use encrypted methods continues, some of these practices need
>> to be re-assessed, and the functions more widely understood than in an era
>> when nearly everything was thought to be TCP or "multimedia".
>>
>
> I'm not sure what you're arguing here. What I said above is that
> this draft was "mostly devoted to documenting the negative
> impact of that change on the operations of those entities."
> In other words, it lists a bunch of things that people do now
> that will stop working. Do you not think that much of the
> material in this draft is of that form?
>
> -Ekr
>
> So the conclusion, para 2 states:
> "   This document has described some current practises, and the
>    implications for some stakeholders, when transport layer header
>    encryption is used.  It does not judge whether these practises are
>    necessary, or endorse the use of any specific practise.
>

I don't really see how this addresses the question we are presently
discussing, which is where I said

"this draft is mostly devoted to documenting the negative
impact of that change on the operations of those entities."

It seems like you disagree with that characterization, but it's not
clear to me why, and this text certainly doesn't address that.


I agree many existing tools would stop working if IPsec formed the majority
> of traffic, same for QUIC. I think when considering what to do next, it can
> be useful to work from the current position and understand the implications
> of changes that are being proposed/used/whatever.
>

At least from my personal position, this document was providing some input
> to that thinking. So, I do not understand your issue.
>
Well, it's pretty far upthread, but see the second paragraph of my review:

   First, it's really not clear what purpose this document serves.  While
   superficially an analysis of the impact of transport layer encryption
   as a guide to designers, in the context of the design and deployment
   of QUIC and SCTP/DTLS, both of which encrypt most or all of the
   transport header, it's hard not to read this document as an implicit
   critique of those decisions. It's not like there's some other big
   transport protocol design effort going on in IETF that would be
   informed by these considerations.

I'm not really sure how to state this more clearly.

-Ekr