Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 10 September 2020 15:46 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F553A0ABB; Thu, 10 Sep 2020 08:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Tjbtc-jiLZxl; Thu, 10 Sep 2020 08:46:11 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94803A0A35; Thu, 10 Sep 2020 08:46:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E9F7389DF; Thu, 10 Sep 2020 11:24:57 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2BI96TKwq3D7; Thu, 10 Sep 2020 11:24:56 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 97C02389D8; Thu, 10 Sep 2020 11:24:56 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E41B8212; Thu, 10 Sep 2020 11:46:07 -0400 (EDT)
To: opsawg@ietf.org
References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: tls@ietf.org
Message-ID: <053b286e-4780-1818-a79d-71b9c967bbd2@sandelman.ca>
Date: Thu, 10 Sep 2020 11:46:07 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5cR7qjVPlV0fwFrFsng7-ZIGmBs>
Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 15:46:13 -0000

On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) wrote:
> Hello, opsawg.  This draft as underwent a number of revisions based on reviews and presentations at the last few IETF meetings.  The authors feel they have addressed the issues and concerns from the WG in their latest posted -05 revision.  As a reminder, this document describes how to use (D)TLS profile parameters with MUD to expose potential unauthorized software or malware on an endpoint.
> 
> To that end, this serves as a two-week call for adoption for this work.  Please reply with your support and/or comments by September 16, 2020.

I have read the document in a number of different revisions, and I 
support adoption.

I have been concerned that this document codifies a kind of TLS snooping 
by middle boxes which has in the past caused significant harm to 
development of TLS. (In particular, TLS version negotiation has had to 
evade existing middle box policies!)

However,  this document seems to walk the fine line between causing 
protocol ossification and providing real security.  To the extent that 
it reduces the pressure by enterprises to invade the TLS encryption 
envelope through use of Enterprise certificates [is there a term for the 
activity describe in section 4.1? I wish there was] this document is a 
very useful thing.

I would like to suggest that upon adoption, that this document go 
through a TLS WG review of some sort before OPSAWG does a WGLC.