Re: [Patient] the IETF participant choice

Ted Lemon <> Mon, 19 March 2018 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36623129C6A for <>; Mon, 19 Mar 2018 13:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wIU_t88QeoXT for <>; Mon, 19 Mar 2018 13:08:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E065D1273E2 for <>; Mon, 19 Mar 2018 13:08:01 -0700 (PDT)
Received: by with SMTP id l9so8338767wmh.2 for <>; Mon, 19 Mar 2018 13:08:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gmbvZTIWI1WiF0rikNydrJOvZfdpNAOKe5cJKHgLNXA=; b=j9/+SqieGeWIGona+UXwEeguKT7W8i948XvKXD1Nsywbx+0jX2yXDe+S/UTufInOOG mpjuMSpN05iA9ohUlE58PG0HwlqtvXolssvz3YKwX20Hp4wYNR0FZXvmJVekEghFJOFG aDK2c5wU7XYOSNPOXpI0gTmDI0BXWjufXyagWUhHkcMjkvOhsO6538/xB359kzrOL9Vu sLmVq6NcaOvKd7ceRvRy7DkoMp4kXUfv1m0Y+S7Ck14ru0ZvvslVN6JlYqsG1NZ7MlyZ cGIY+91GUnZO4MwWeEJwBEELdCZv4YpxnJ1StiFfUHCljZwZXagC0xeurIUTdNjYAB05 /muQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gmbvZTIWI1WiF0rikNydrJOvZfdpNAOKe5cJKHgLNXA=; b=pExE+1MJkQwo0hbjFdKHl434j+QqvExWRWnZPOHxP3CMcR0F7ljLBPGsQ/eoPB3ngp v5FQDkGvmo5dm/MVZJXgKwTuhXY9IB2MaQ7IYoYbj8YTZzO4ZrLxZple5GgliM4PMBKB W2/eEAahLixVuBVwwjFX9seUVQnX9g3szzSX7KzyMQXLSOpZtgQkL0PFAQ69bZ5dDvTB C7sk8YIwrjeYxHCBeTXgqmiHKL57WfBCkGHy+aUY5Asyxgb2TKLT+GjyPEEboPZQY5dB SZdFLuhvHgQhH+qUTdKvD71B5aQluuTI2NeRw5qdrQUf0a1wVUfzSdPzueiE3uR96pyG 32gQ==
X-Gm-Message-State: AElRT7EWub5PsER7GzGotYi98UlE+z2AMTLQAR87yz7ntA7GznkVhbrq zO9bCrsMgdgEw+JMBH+lE8xs7w==
X-Google-Smtp-Source: AG47ELvkbd6lOspb2JxudJFyLghdj/vsBm1KVqzwK+/S+GK4l7cq50VMZBpsVB+EU9CHHXqFEA9acQ==
X-Received: by with SMTP id t5mr40885wme.116.1521490079689; Mon, 19 Mar 2018 13:07:59 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k18sm22188wmd.4.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 13:07:58 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F7D26365-81D2-457D-8148-0014E70CCA42"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 19 Mar 2018 20:07:57 +0000
In-Reply-To: <>
Cc: Brian Witten <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [Patient] the IETF participant choice
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Mar 2018 20:08:04 -0000

On Mar 19, 2018, at 8:01 PM, Tony Rutkowski <> wrote:
> In participating remotely, it was apparent that although the proponents of the data centre visibility proposal did an excellent job in articulating the need, the solution was not going to be undertaken by the IETF.  The result in consonant with countless other similar initiatives sought in the IETF over the past several decades.

The thing is, at least from my perspective, we haven't done a systems analysis yet, and so it was just premature to try to get the TLS working group to weaken TLS in order to solve the problem.   For example, the claim was made that it would be "too expensive" to do anything _other_ than modify TLS, but where's the analysis to support that position?   Too expensive to use middleboxes, but where's the analysis there?

This is really an ops problem.   IETF can do ops work, but ops isn't about changing protocols—it's about figuring out good solutions to problems.   Sometimes the answer to an ops problem is "we need some protocol work done," but that's not the starting point.

As a consequence, I feel like some very well-meaning people came to the IETF with hat in hand and didn't get what they'd hoped for, and probably have the impression that people here don't care about their problem, when that's not actually the case.   Lots of people I talked to who were against the proposed solution care very much about the problem.