[OPSAWG] Secdir last call review of draft-ietf-opsawg-mud-tls-10
Linda Dunbar via Datatracker <noreply@ietf.org> Fri, 18 November 2022 17:27 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D422BC1524D1; Fri, 18 Nov 2022 09:27:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Linda Dunbar via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-opsawg-mud-tls.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166879247786.62318.15372394698104176531@ietfa.amsl.com>
Reply-To: Linda Dunbar <linda.dunbar@futurewei.com>
Date: Fri, 18 Nov 2022 09:27:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ibIcT54v51DY2FjuASSNuBiStf8>
Subject: [OPSAWG] Secdir last call review of draft-ietf-opsawg-mud-tls-10
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 18 Nov 2022 17:27:57 -0000
Reviewer: Linda Dunbar Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last-call comments. This document extends the Manufacturer Usage Description specification to incorporate the (D)TLS profile parameters for a network security service to identify unexpected (D)TLS usage. The document has very good description of common malware behavior that is informative. Questions - Are the profile on the remote IoT device or on the network device? If the profile is on remote IoT devices, are those attributes in the profiles attached as metadata when requesting TLS connections? Are those attributes encrypted? - If the Malware on IoT doesn't participate in TLS, can those MUD be used to detect the Malware on the remote IoT devices? - Page 6, first paragraph says: "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." Does it mean that if all the IoT devices deployed in the network register their DeviceType/ManufacturerName/Model with the network services, then the network services can validate the TLS requests from the IoT? - Section 3 last paragraph says that "compromised IoT devices are typically used for launching DDoS attacks". Can today's TLS re-negotiation validate the TLS requests by evaluating if the server certificates are signed by the same certifying authorities trusted by the IoT device"? Thank you very much, Linda Dunbar
- [OPSAWG] Secdir last call review of draft-ietf-op… Linda Dunbar via Datatracker
- Re: [OPSAWG] Secdir last call review of draft-iet… tirumal reddy
- Re: [OPSAWG] [secdir] Secdir last call review of … Ben Schwartz
- Re: [OPSAWG] [secdir] Secdir last call review of … tirumal reddy
- Re: [OPSAWG] [secdir] Secdir last call review of … Ben Schwartz