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

Eliot Lear <lear@cisco.com> Tue, 15 September 2020 09:21 UTC

Return-Path: <lear@cisco.com>
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 647343A0BB1; Tue, 15 Sep 2020 02:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 v1cOSblXjczD; Tue, 15 Sep 2020 02:21:56 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50D23A0C06; Tue, 15 Sep 2020 02:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2488; q=dns/txt; s=iport; t=1600161716; x=1601371316; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=g1+NKIIoD4nkGpn5Gj2xP+wu51WUKKm7E0PQ2P2S+9o=; b=DOuH5CwhgNhxeKj5MEFMwyiKSUr5+cs5Ltvk90nwsFw8vNBC+G9vii5J dLnzf9twJkFa8+R4ap95lTU6dfb54lV/Qa7AoXNfexo6obij2zrN0jXTP CJo3nWfDj+INjdop2FVE/QjYPzhOXdSO9Ub3dhEVqyVG9nOrutrrEi5HF Q=;
X-Files: signature.asc : 488
X-IPAS-Result: A0A4AAAih2Bf/xbLJq1gGwEBAQEBAQEBBQEBARIBAQEDAwEBAYF+AwEBAQsBg24BIBKEZYkCiDacHQQHAQEBCgMBAS8EAQGESwKCHiU3Bg4CAwEBAQMCAwEBAQEFAQEBAgEGBG2FaIVzAQQBHQZWEAtCAgJXBoM5AYJcILR7doEyhVOFBRCBOAGBUot0ggCBESccgk0+h1Qzgi0EkmYBiHGbN4JvgxGBMJYBAx6DCYl1hQ6JH4VDrnmDWgIEBgUCFYFqJIFXMxoIGxVlAYI/PRIZDVYCnBA/A2cCBgEJAQEDCZBQAQE
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.76,429,1592870400"; d="asc'?scan'208";a="27186044"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Sep 2020 09:21:51 +0000
Received: from [10.61.236.14] ([10.61.236.14]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 08F9Lpq6008295 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Sep 2020 09:21:51 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <5F503ED8-38B0-414A-906A-FE8DCF94AC92@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_FDC4E405-DA15-4D16-B0BB-DE91FACB4ADF"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 15 Sep 2020 11:21:50 +0200
In-Reply-To: <CAHbrMsBLrGsg+beMhNadqs+QC9icOsGLxLJYGghEg339=c0b0Q@mail.gmail.com>
Cc: tirumal reddy <kondtir@gmail.com>, Nick Lamb <njl@tlrmx.org>, opsawg <opsawg@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
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> <CAFpG3gdRUAAYmvV1+m=+4_0GUd_SDS0hZHhpSXa2qQ6Civtf-g@mail.gmail.com> <CAHbrMsD=BOxYLaJyOkv-t9p+Cm4cEpOui7sQdL9Mmfi=Ufh3mA@mail.gmail.com> <7207C73E-FB80-4BD3-AE68-627355B10708@cisco.com> <CAHbrMsBLrGsg+beMhNadqs+QC9icOsGLxLJYGghEg339=c0b0Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Outbound-SMTP-Client: 10.61.236.14, [10.61.236.14]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/o8B21UzJEZG7DS4HaJRFdZeXEdQ>
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: Tue, 15 Sep 2020 09:21:58 -0000

Hi Ben

Thanks for the response.  Please see below.

> 
> Agreed ... but this proposal appears to be predicated on a contrary assumption.  It assumes that it is difficult for malware to learn the TLS profile of the device, and then proceeds to place this profile information in the (public) MUD file, where malware can easily retrieve it.

Ok, I didn’t take that from this discussion.

> 
> I'm not thinking of the hours-days timescale of MUD file updates; I'm thinking of the months-years timescale of updating standards to support new features.  How long does a device have to wait after a new protocol revision comes out before it can start using the new protocol?

Ok, I see what you are saying.  Thanks for getting me there.

The question is what to do when you start seeing something you don’t understand.  Let’s take a TLS extension, for instance.  If the TLS extension is unknown to the f/w but is declared somehow, that tells the firewall that they have some coding to do, and should be conservative about complaining over something that is out of profile.  I don’t see that as a show stopper.  What I do see as a showstopper would be if, as is written and you rightly observe, a new rev of a YANG model is required to introduce the TLS extension, so that part would need to be described in a more flexible manner (e.g, an IANA registration or similar).  I’d suggest the authors consider that.

Eliot