Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt
Michael Richardson <mcr+ietf@sandelman.ca> Sat, 18 January 2020 02:27 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308461200BA for <opsawg@ietfa.amsl.com>; Fri, 17 Jan 2020 18:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WRD_BxBHG0zY for <opsawg@ietfa.amsl.com>; Fri, 17 Jan 2020 18:27:42 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38082120041 for <opsawg@ietf.org>; Fri, 17 Jan 2020 18:27:41 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E8BBD3897D for <opsawg@ietf.org>; Fri, 17 Jan 2020 21:27:11 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 97D7710FC for <opsawg@ietf.org>; Fri, 17 Jan 2020 21:27:40 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: opsawg@ietf.org
In-Reply-To: <CAFpG3gek8qrHjN5LNQUrRrS9+zFuVQQ4y+XorRrr5xySs2fP1g@mail.gmail.com>
References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <CAFpG3gehp98VB2RpL6LenRJsV=RRQ=1jCTX7mcrmd27pzkYqfg@mail.gmail.com> <CAFpG3gek8qrHjN5LNQUrRrS9+zFuVQQ4y+XorRrr5xySs2fP1g@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 17 Jan 2020 21:27:40 -0500
Message-ID: <20570.1579314460@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/RLUZfhnnXtdsSFGL8Zy7MBffQo4>
Subject: Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jan 2020 02:27:45 -0000
tirumal reddy <kondtir@gmail.com> wrote: > This revision > https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02 updates the > draft to discuss privacy enhancing technologies and evasion techniques > used by malware, visibility into TLS 1.3 parameters and how certain > types of malware can be blocked without acting as a (D)TLS 1.3 proxy. > As a reminder, this draft extends Manufacturer Usage Description (MUD) > to incorporate (D)TLS profile parameters. This allows a network > element to identify unexpected (D)TLS usage, which can indicate the > presence of unauthorized software or malware on an endpoint. I have read opsawg-mud-tls, and I am in general very very reluctant to provide detailed instructions on doing innovation kill intrusive DPI. I think that it will ultimately not result in any improvements to network security. I see two advantages of this work, which mitigates my concern slightly. (but, only slightly) 1) if it's gonna get done by IDS vendors, then IoT device manufacturers might as well provide a way to help them *get it right* 2) it seems that manufacturers might be able to say, "HANDS OFF" to IDS systems. (perhaps avoiding use of more colourful language) The document says: In other words, malware developers will have to develop malicious agents per IoT device type, manufacturer and model, infect the device with the tailored malware agent and will have keep up with updates to the device's (D)TLS profile parameters over time. Further, the malware's command and control server certificates need to be signed by the same certifying authorities trusted by the IoT devices. Typically, IoT devices have an infrastructure that supports a rapid deployment of updates, and malware agents will have a near-impossible task of similarly deploying updates and continuing to mimic the TLS behavior of the IoT device it has infected. It seems to me that malware will know exactly, thanks to this extension how to perfectly impersonate the device. Given that TLS1.3 makes so many of the characteristics of the implementation less visible, it seems that this is just a dangerous arms race. As border MUD gateways get more detailed in the way they examine things, the ability to innovate in TLS will simply diminish. It is my understand that we already had to do the TLS 1.3 version negotiation differently thanks to middle boxes because of such nonsense. I don't think that section 4.1 needs to explain how BRSKI works. In any case, it's not BRSKI that matters, but EST(RFC7030)'s /cacerts. I see that it's probably difficult to get to RFC7030 just to run /cacerts, but if BRSKI is being used already. {If this gets better IoT onboarding into Enterprises.... well. What a Faustian bargin...} I believe that attempting to auto-configure a TLS 1.3 MITM proxy using EST is a really bad idea. Devices that are willing to fall prey to such a "friendly-fire" attack would seem to be broken to me, period. I suspect that US HIPAA legislation and probably European GDRP might well make such a MITM a serious privacy violation. Any medical device that communicates patient data that could be spoofed like this might be considered to be violating. Additional, it is entirely reasonable (perhaps, given MITM attacks!) for an IoT device manufacturer to "call home" using a baked in, non-public, trust anchor. Such a situation would be indiguishable from malware calling C&C using a baked-in trust anchor. I would certainly want to do this for firmware updates. Given that MUD can clearly control where connections are made, it seems to me that much of this effort is a mis-guided relic of pre-MUD DPI IDS systems. I suggest that section 4.2 reference draft-richardson-opsawg-mud-iot-dns-considerations-01. I didn't understand the purpose of the SPKI pin info mentioned in section 5. I suggest that you remove details from this overview section, and list just the high-level and leave the details for a section on each part. As far as I can tell from the YANG module and the example, the stated TLS profile appears to apply to any/all TLS traffic coming from the device. I would have expected it to be expressed on a per-port outgoing/incoming basis. (Perhaps defining the profile(s) once and then re-using it) -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [OPSAWG] Fwd: New Version Notification for draft-… tirumal reddy
- Re: [OPSAWG] New Version Notification for draft-r… tirumal reddy
- Re: [OPSAWG] New Version Notification for draft-r… Michael Richardson
- Re: [OPSAWG] New Version Notification for draft-r… tirumal reddy
- [OPSAWG] how to increase trust in MUD URL Michael Richardson
- Re: [OPSAWG] New Version Notification for draft-r… Michael Richardson
- Re: [OPSAWG] New Version Notification for draft-r… tirumal reddy
- Re: [OPSAWG] New Version Notification for draft-r… Michael Richardson
- Re: [OPSAWG] New Version Notification for draft-r… tirumal reddy