Re: [Patient] [EXT] Re: the IETF participant choice

Tony Rutkowski <> Tue, 20 March 2018 11:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29094126CD6 for <>; Tue, 20 Mar 2018 04:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2xpuPIWoNbVh for <>; Tue, 20 Mar 2018 04:09:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EB3C124319 for <>; Tue, 20 Mar 2018 04:09:51 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id CE317540481; Tue, 20 Mar 2018 11:09:49 +0000 (GMT)
To: Brian Witten <>, Ted Lemon <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tony Rutkowski <>
Organization: Yaana Limited
Message-ID: <>
Date: Tue, 20 Mar 2018 07:09:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3D5C9E0ABF727EC1D570655D"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Patient] [EXT] Re: 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: Tue, 20 Mar 2018 11:09:53 -0000

Hi Brian,

The entire world resonated with those use cases. :-)    Of course, that 
was foregone.  The Use Case Annex to the ETSI MSP draft spec has about 
six sub-sections running five pages!  That took some careful editing 
given the several thousand published materials that articulate the use 
cases, as well as ongoing work in other bodies.

The challenge has been sifting through the dozens of different 
techniques that have already been published in research papers, 
standards bodies, and patent applications for accomplishing the required 
observability with the desired granularity controls.

The ancillary challenge has been the proactive outreach of continually 
discovering and engaging with the numerous diverse communities who want 
the observability capabilities ASAP.  They are ultimately the customers 
for the specifications, and will likely produce derivative versions to 
meet their own industry or sector needs.  When there is this kind of 
demand, it is race against time before the existing proprietary 
solutions extensively proliferate.

The initial stable versions of the network specs will be available 
shortly in preparation for the June workshop and hackathon.  The data 
centre specs will follow shortly afterwards.


On 19-Mar-18 7:57 PM, Brian Witten wrote:
> Hi Tony,
> Thank you for your note!  I very much empathize with the pains of 
> remote participation, and it's very unfortunate that the dates 
> conflicted for SG 17 this week as we clearly both have colleagues and 
> friends at both events.  I personally applaud the work in both ETSI TC 
> Cyber and ITU SG 17, along with the work in the IETF TLS WG.
> In person, here at the IETF, I got a bit of a different feeling than 
> you described from remote participation.  In person, I heard more 
> emphasis on the valid technical concerns which were raised, concerns 
> which focused on the proposed protocol, not the use-cases.  We heard 
> additional requirements not yet factored into a design. Of course, the 
> "passive-listener / off-line decrypt" challenges which rhrd (tonight's 
> hum) attempted to address are not the same as the "in-line, actively 
> acknowledged proxy," challenges which PATIENT has been discussing. 
>  Still, I was glad to see Steve Fenter's use cases received "better 
> than at least I had expected," even if the proposed draft protocol 
> design was not accepted.
> I believe that the authors have the option to either (a) 
> propose directly to the Security Area Directors a new protocol better 
> addressing the requirements emphasized in discussion tonight, so that 
> the AD's can decide whether TLS WG discussion of a third design is the 
> right best next step, or (b) consider pursuing formation of a new WG 
> such as through a BOF process.  I'm not sure which they'll do, but I 
> look forward to learning that from the SAAG and/or TLS WG lists.
> Please LMK if I can help more -
> Best,
> Brian
> ------------------------------------------------------------------------
> *From:* Tony Rutkowski <>
> *Sent:* Monday, March 19, 2018 2:42:18 PM
> *To:* Ted Lemon
> *Cc:*; Brian Witten
> *Subject:* [EXT] Re: [Patient] the IETF participant choice
> Almost every venue does things pretty much this way.
> No fora exists to solve all the world's network operational problems.  
> "Sorry, not our problem" is an acceptable answer. Those venues that 
> don't have that option, when appropriate, are probably best avoided.
> --tony
> On 19-Mar-18 5:23 PM, Ted Lemon wrote:
>> There are individuals who show up here to talk about why they need 
>> stuff and use their own operational problems as examples. That's how 
>> we always do this. It's really a process of successive approximation.