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

Ben Schwartz <bemasc@google.com> Fri, 06 January 2023 16:13 UTC

Return-Path: <bemasc@google.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 8D97FC185B96 for <opsawg@ietfa.amsl.com>; Fri, 6 Jan 2023 08:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.597
X-Spam-Level:
X-Spam-Status: No, score=-17.597 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, ENV_AND_HDR_SPF_MATCH=-0.5, 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 BGP8FeVgrykF for <opsawg@ietfa.amsl.com>; Fri, 6 Jan 2023 08:13:33 -0800 (PST)
Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 D825DC14F722 for <opsawg@ietf.org>; Fri, 6 Jan 2023 08:13:33 -0800 (PST)
Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-4a2f8ad29d5so28595407b3.8 for <opsawg@ietf.org>; Fri, 06 Jan 2023 08:13:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=VPk6SZ0pAPjEdYWYKollWNzE6rxd4HcCepc/L7aEvL0=; b=U5cfifp8BssanzJi8ur5GaveePJhWQXA19K7JTnqGjh1KP4k1oJf0+A+UNIqSU3XIl 22rcPBjocGSiRaS59dsThQRncwC6/6kauK4LnL6yJXVBJFg5Bz2CvfILbeNeaq4PIS3S ydij0qkpSPCHWM4aUs3EyGuhFdLsy8lkMm1xre1Iax0LddRWNuk0+9/FJ8ANdMCrfFmi yORo02EVqJI1FqzJil1u36ejNmTua9XDMKfdPA92PmROJ2q7lWVR7Q0t5AoqzaiyYJuu N7RbPLm9enYe+oRkI9hYHwMdfqvw1JzRtjYOiaoPlCyPRl/6WWjXdS7Y9hmS32nA5ZYk lUgw==
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=VPk6SZ0pAPjEdYWYKollWNzE6rxd4HcCepc/L7aEvL0=; b=wvJvtgyA9I4cch4zkjwMdoXCKq4W8VnQQxHgSyTCAJqBPnR+Uq6wxOpf4GEKGIp+ro KCK6l0B18IhnnOQDeRljp754M4Nmgc9OKwTB8LxSfy0oHSgUa8xHdFZBVEeXfHf9POyO UicW1+2ZCrwoDP/jyrZk2LTv3z9UmCje/6rblc5yaA/q4t8p+B+R8LC0wqCemEbbUR+9 ewOGdUd13JUWysiHCouvEdLxJIJA5XP++fpdj6l+R6k3KizXOl8SzPez7/12ffMg/6f+ KRK00x9oGjoBj+J5ciHwmsjzjSCbW0JmrbaEBjRXgyANTnuryRKn68oLpV8Jikk02ZrV n2zQ==
X-Gm-Message-State: AFqh2kpZArlsF5s0MtFFThzlwE+zthvRAxrJ3itQck9jguODRVNdklm6 W0b/0TUis6AcH8Q/ThwN5D/yynMu1T2jocPkNvEBNQ==
X-Google-Smtp-Source: AMrXdXvPefTqfvOys2kxwJ+SZeZ3bkkwNETP2TqITf3Jc6fzmN4Mq6xrFM77Zz5BxZbfhoAhd+KeEoZqeZHWhIPO7yA=
X-Received: by 2002:a05:690c:b06:b0:467:c38e:b38f with SMTP id cj6-20020a05690c0b0600b00467c38eb38fmr129041ywb.361.1673021612722; Fri, 06 Jan 2023 08:13:32 -0800 (PST)
MIME-Version: 1.0
References: <166879247786.62318.15372394698104176531@ietfa.amsl.com>
In-Reply-To: <166879247786.62318.15372394698104176531@ietfa.amsl.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 06 Jan 2023 11:13:20 -0500
Message-ID: <CAHbrMsCrCXe68f1YAH=p4vo7=ESuGUEjmAW+T6SovCMyhA75Gw@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/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000f50e4f05f19ab231"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/OIp1jhp2LL9tUhZDNA2AHiO6vDQ>
Subject: Re: [OPSAWG] [secdir] 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 16:13:38 -0000

Since this happened to cross my inbox, I want to reiterate that, in my
view, this document has not been properly reviewed by the TLS WG.  As the
shepherd's writeup notes, previous reviews in the TLS group raised some
significant concerns about whether this draft's approach is advisable.

I would encourage the responsible AD(s) to make sure that this document has
strong consensus support from the TLS WG before proceeding.

On Fri, Nov 18, 2022 at 12:29 PM 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? 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
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
>