Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-mud-tls-10

tirumal reddy <kondtir@gmail.com> Fri, 06 January 2023 07:45 UTC

Return-Path: <kondtir@gmail.com>
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 D7B72C14CE37; Thu, 5 Jan 2023 23:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDG05T5wEICk; Thu, 5 Jan 2023 23:45:42 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A580C14CF04; Thu, 5 Jan 2023 23:45:42 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id e13so762474ljn.0; Thu, 05 Jan 2023 23:45:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7QfBc39nQ/xFKykL99EhK5HedplXzUu3V7fF+HpBoIk=; b=ARUqaWKWRARMnJzDQPiaJ8FM4K9wCxIB9x61RuTUVwYzNxJgPYYfVB0pDjKRmSoVbk RTPiKQC6rhJneHep2xD+vcIkqBZ6apDYLYZYauLeygylfisax8Ah2FAsDb3plvEm66IA HByKSo+txVNlmxGfbSo0ch5Pz1R3Ro/VRPAIKNAgV15MRimPlJBa52SVd7LBWZdmv7Ta TVH1fbdNruSxh5x+Wb+UGy9fAMi+mzdrryzxYN2ApjXETmdzkljnDnzOVLgVF97QGYb/ y0Hj7LQb3jQbtjputH9H7IpUBxo9xbIJxRbvoip/qdTH0zxs2aFBTdPBxYE/Ft/Y+Cgm Px5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7QfBc39nQ/xFKykL99EhK5HedplXzUu3V7fF+HpBoIk=; b=u1YEMAjhodkR3AznnSxl8wg+MQswDvEAW5TN971RQXAiLbnrYx72IqDO/TPsZUAsls P7JAmMiQJqkJCFoiuOyV+Y/K/SVYgI63vt8Pe30ncOY4VXR9Ioq2uyvJkiMDUzvf+I4x ZwvU+8p3mIXe36vyx8qX3DStWt+e4NMb90MV+Urm/EeFvj5nYI+gdmPXS45/FFXthFVk yqr6yloLCDHrOrZQNvuDDkHRglEcOPiKtLQ7dc83P+xFZEc5/pu57ybU01CIzWDChYhV LUfxlMKBu8vpZcmDopdvbPTKLA0f2d5Ih28/ESBDRt8LeO+/Aw1f460OQgPaYngDW85W 3ryw==
X-Gm-Message-State: AFqh2kpQTar2f3vCI7Odww3MMayhM4VV1atn+IyqrURpqV9KBTsB2dqR MdmmJOSIc+dyH6+XJKz1D8O+aMmFP+e2FVAVXswL4rVkFJI=
X-Google-Smtp-Source: AMrXdXsjDLe1jUiPed6NffhVnxt632m03J99T0vh56QNSH8tvHED6YzBof+ZPfz1SGII6PfIAu3ft5etMKceXuF3oPY=
X-Received: by 2002:a2e:9d4f:0:b0:27f:f286:15e9 with SMTP id y15-20020a2e9d4f000000b0027ff28615e9mr1256708ljj.403.1672991140227; Thu, 05 Jan 2023 23:45:40 -0800 (PST)
MIME-Version: 1.0
References: <166879247786.62318.15372394698104176531@ietfa.amsl.com>
In-Reply-To: <166879247786.62318.15372394698104176531@ietfa.amsl.com>
From: tirumal reddy <kondtir@gmail.com>
Date: Fri, 06 Jan 2023 13:15:28 +0530
Message-ID: <CAFpG3gd547c7tJ7FUWudj9U+6_UG_9WLKC_ROfWEjY7Nm=enpg@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org, draft-ietf-opsawg-mud-tls.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a0302205f1939a0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/DH9aC_gNVoNxOdjOdc-wghbKmOU>
Subject: Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-mud-tls-10
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 06 Jan 2023 07:45:46 -0000

Hi Linda,

Thanks for the review. Please see inline

On Fri, 18 Nov 2022 at 22:58, Linda Dunbar via Datatracker <noreply@ietf.org>
wrote:

> 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?


The TLS profile on the IoT device is signalled to the network device using
MUD (see https://datatracker.ietf.org/doc/rfc8520/) .


> If the
> profile is on remote IoT devices, are those attributes in the profiles
> attached
> as metadata when requesting TLS connections?


No.


> Are those attributes encrypted? -
>

Yes, the TLS profile is learned from a MUD file, it will be retrieved
using the "https" scheme.


> If the Malware on IoT doesn't participate in TLS, can those MUD be used to
> detect the Malware on the remote IoT devices?
>

If the IoT device is supposed to use TLS as per the MUD file, but the
firewall sees some other type of traffic from the IoT device it cannot
identify, it can assume malicious traffic and can take
appropriate action.


>
> - 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?
>

Yes, it is extending MUD which defines layers 3 and 4 ACLs for IoT devices.


>
> -  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"?
>

In this attack, the client completes the TLS handshake but then immediately
requests a renegotiation of the encryption method. As soon as the
renegotiation completes, it requests another renegotiation, and so on to
cause
an attack on the server.

Cheers,
-Tiru

>
> Thank you very much,
>
> Linda Dunbar
>
>
>