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

Nick Lamb <njl@tlrmx.org> Wed, 23 September 2020 21:15 UTC

Return-Path: <njl@tlrmx.org>
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 0AC573A1591; Wed, 23 Sep 2020 14:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=tlrmx.org
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 ceH_uU3yQdIM; Wed, 23 Sep 2020 14:15:11 -0700 (PDT)
Received: from eastern.birch.relay.mailchannels.net (eastern.birch.relay.mailchannels.net [23.83.209.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40043A1517; Wed, 23 Sep 2020 14:15:07 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C59ED64107A; Wed, 23 Sep 2020 21:15:06 +0000 (UTC)
Received: from pdx1-sub0-mail-a33.g.dreamhost.com (100-100-138-6.trex.outbound.svc.cluster.local [100.100.138.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AE9CC641491; Wed, 23 Sep 2020 21:15:00 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org
Received: from pdx1-sub0-mail-a33.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Wed, 23 Sep 2020 21:15:06 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|njl@tlrmx.org
X-MailChannels-Auth-Id: dreamhost
X-Bottle-Wiry: 08fc7d5f3dedf762_1600895700969_4288015314
X-MC-Loop-Signature: 1600895700969:1261585438
X-MC-Ingress-Time: 1600895700968
Received: from pdx1-sub0-mail-a33.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTP id 26BE64ED7F3; Wed, 23 Sep 2020 14:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tlrmx.org; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=tlrmx.org; bh=OsEVQy2 rZbGQ4WyyYSWvaVtC2ik=; b=N+pG/QT5idiTZKJv5YC8Z+Crmai/JAjE0esplSk nOHaNcf+J8NVSSArPvWDScsXg29KxmEeTlTgTM+SDqo60U2ZptA6nkUVsqYdZTBd arev/SRVavkCTcEYYfv/pXfIVq5/TO173A02+95N3DIhyxDuMAVkR6aUoKgJxue1 isJ4=
Received: from totoro.tlrmx.org (124.89.2.81.in-addr.arpa [81.2.89.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: njl@tlrmx.org) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 410324ED7F2; Wed, 23 Sep 2020 14:14:58 -0700 (PDT)
Date: Wed, 23 Sep 2020 22:14:54 +0100
X-DH-BACKEND: pdx1-sub0-mail-a33
From: Nick Lamb <njl@tlrmx.org>
To: Eric Rescorla <ekr@rtfm.com>
Cc: opsawg <opsawg@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20200923221454.123f0254@totoro.tlrmx.org>
In-Reply-To: <CABcZeBMdra=1Rhum7ky1sj_AnNbK7GOJzKJNMZJvQJtfgGe_cg@mail.gmail.com>
References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com> <053b286e-4780-1818-a79d-71b9c967bbd2@sandelman.ca> <CAHbrMsANEA4omTm5dPYLN9zGde2YdT_71ujpBcCEer_xSkPhbw@mail.gmail.com> <CAFpG3gepojPJoK8W+o9Qr66gPSUqHY+sDX-v+-fuwcM9Y56C_g@mail.gmail.com> <20200911114054.184988dc@totoro.tlrmx.org> <FF4995F8-53F1-450B-A305-A095A7BAE057@cisco.com> <CAFpG3gcS951QfTZb+qFstjnBxfxP54B=VDSSPP3xyP3dtuabQg@mail.gmail.com> <CAHbrMsD5qj2ovcUVMRYStXN01RiX2RiJ+N8cakeGPH3wU2nqBQ@mail.gmail.com> <CAFpG3gd9OTZexW9_XCmeO-2uBc8OcVx5HJzs1Qq-zR8zAbnmGg@mail.gmail.com> <CABcZeBMdra=1Rhum7ky1sj_AnNbK7GOJzKJNMZJvQJtfgGe_cg@mail.gmail.com>
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eGS_TaMUf6b-_Nslc_1UotfPMY4>
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: Wed, 23 Sep 2020 21:15:17 -0000

On Wed, 23 Sep 2020 05:51:24 -0700
Eric Rescorla <ekr@rtfm.com> wrote:

> I think this misunderstands the point.
> 
> Suppose I want to add feature X. There are (at least) two scenarios:
> 
> 1. Add a new feature and it just works.
> 2. I have to get it added to the YANG module, then get middlebox
> vendors to change their software which may involve introducing some
> new parser for that feature, then I can publish a policy, and it
> works.
> 
> Option (2) is going to take much longer to happen than option (1).
> Depending on how slow the vendors are, it could be indefinitely long.
> Given that it's often not viable to roll out new networking features
> if they introduce any significantly increased risk of failure, this
> seems like a recipe for ossification.

Perhaps the draft could instead be written in terms of allowing any 
TLS behaviour *except* behaviours the Thing promises (via a MUD file)
never to use.

For example a Thing might promise it doesn't do outbound TLS 1.1 or
earlier, and then a compliant MUD manager can block or alert on TLS 1.1
or TLS 1.0 connections purportedly coming from the affected Thing.

Or perhaps this Thing is designed to receive connections from another
Thing and the MUD policy promises these will never use RSA kex, so the
MUD manager can block or alert an attempt to use RSA kex.

This seems like it avoids the MUD TLS YANG module needing to chase the
bleeding edge of TLS development. A TLS feature only becomes relevant
for this "ratchet" approach once there are better alternatives that
Things should reasonably be doing instead of that feature, likely 
years after the feature is in wide use and well understood.

That could apply appropriate back pressure to Thing vendors. If your
Thing lacks the "I don't do outbound TLS 1.0" node in its MUD file then
the question is, does it actually still do TLS 1.0? If it doesn't, a
newer MUD file can be provided which says it promises not to. If it does
still do TLS 1.0 that's a security policy risk for the owner to
understand and perhaps decide to mitigate by whatever means they prefer.


Nick.