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

tirumal reddy <> Sun, 20 September 2020 07:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A34463A0E70 for <>; Sun, 20 Sep 2020 00:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lm0p-YjBGWZt for <>; Sun, 20 Sep 2020 00:18:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81B133A0BA4 for <>; Sun, 20 Sep 2020 00:18:27 -0700 (PDT)
Received: by with SMTP id y9so10763034ilq.2 for <>; Sun, 20 Sep 2020 00:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dV7wnXUeZCQ7fMQrBH8p8Hdae2lc67MiuECR2pT2FkE=; b=BuTGgV9C1BiqgS34JlnedwwzC8Pl8PMBrHGm3t9BX0NT9vJe/ZChpSY26A323A4oUM S0pDjym2EelN4fzY5A1Z5hr9jUPJCnIWtdBfxnrkBNXprNtotJz+gR/Xnfpxxy0juFf1 g+i/jqH67nHlIlNB1sUjzpjAD+HZnU0ORYj3swSUvRVxztKucTKQlP7axn2WEnSqYcdO BoOvGfFkHLWSV2D+uEY8uoExsNoymOZaP9fvBDZGZ8eiBz9L0uOCS+ZRsCs8oo7bmZN1 X3NFXqAjkBxxaXxo/fEAt0Od2xH/gFimjpQKPwMj7LzlKSmHPgLhNK//lU1p5OhcnPQi k64g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dV7wnXUeZCQ7fMQrBH8p8Hdae2lc67MiuECR2pT2FkE=; b=TBejxbn2piQyQLO5w7iDYEJa9DM1bErScA92cupGHpMIW/a8lYE0KQW2GyIc9g/sNH Zx0EOO5XUvcb0Z8Dbbmm13rIwFQAat0cJPuQvP0Q0C7oKrivkYBMs7r1GCGd5tNo37P3 FmkAekeKzwCtGRyK+F9TN3+MBCUwt6GtA93YWIiYWOpWm6G3CjEsDvGOzDsdlBm0cKhH n59ecWWqgVJ9xEHebzCgDkeK4wayYPsuN+A83Z+GHvFqMEmuzPzYuXmn1M25qwDtAc/M 4RuhR9sSlvUPSUHmj5khm4gy4f0K/HzWP7QDcy0v2mvs4wjwhHfF6pVM6yQX9VkBorNP Otng==
X-Gm-Message-State: AOAM531VTd7E8/9rd34yAXugwwUQKn8GhIO04a4Kuu991htzHcT+Dzhu YNQjME32g/rgoGtq+eP+eVHuMTyQXs+SbyLzvac=
X-Google-Smtp-Source: ABdhPJz0/mft5XQi14eWHwazaOomB2HjfuN+xrbOKpUR5KekoTLSyDhpWvKpBkwJ5rRW/jdzwPPSuJUqYI6j3HC1x5w=
X-Received: by 2002:a05:6e02:11:: with SMTP id h17mr16948684ilr.300.1600586306564; Sun, 20 Sep 2020 00:18:26 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: tirumal reddy <>
Date: Sun, 20 Sep 2020 12:48:14 +0530
Message-ID: <>
To: Qin Wu <>
Cc: "Joe Clarke (jclarke)" <>, opsawg <>
Content-Type: multipart/alternative; boundary="0000000000003c362d05afb98ae7"
Archived-At: <>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Sep 2020 07:18:30 -0000

Hi Qin,

Thanks for the support and review. Please see line

On Mon, 7 Sep 2020 at 07:37, Qin Wu <> wrote:

> Support adoption of this work.
> I have a few comments which I would like authors to consider:
> 1. Module name I strange, should not include surname and WG name in the
> standard module name, suggest to change it from
> reddy-opsawg-mud-tls-profile into ietf-mud-tls-profile

Sure, will change after the draft is adopted by the WG.

> 2. Can we still see this module as "ietf-mud" extension module? since
> reddy-opsawg-mud-tls-profile is not augmentation of ietf-mud module any
> more in v-03

It specifies an extension to ACL similar to the way RFC8520 augments ACL.
"ietf-mud" module can contain the extended ACL with MUD (D)TLS profile. For
example, see

> 3. Section 3 said:
> "
>    The compromised IoT devices are typically used for launching DDoS
>    attacks (Section 3 of [RFC8576]).  Some of the DDoS attacks like
>    Slowloris and Transport Layer Security (TLS) re-negotiation can be
>    detected by observing the (D)TLS profile parameters.  For example,
>    the victim's server certificate need not be signed by the same
>    certifying authorities trusted by the IoT device.
> "
> How do you make sure you can detect DDoS attacks by only observing DTLS
> profile parameters? What about Legitimate IoT device's server certificate
> is also signed by the same certifying authorities?
> You may block legitimate IoT devices who did TLS re-negotiation?

MUD (D)TLS profile will not identify TLS renegotiation attack but can
identify the IoT device is not supposed to communicate with the victim
server. For example, the victim's server certificate need not be signed by
the same certifying authorities trusted by the IoT device.

> 4. Section 4.1 said:
> "
> In other words, the
>    scope of middle-box acting as a (D)TLS proxy is restricted to
>    Enterprise network owning and managing the IoT devices.
> "
> How do I make sure middle box acting as DTLS proxy is not man in the
> middle attack? Is there mutual authentication mechanism which can be used?
> How do I authenticate middle box is a trusted entity?

Middlebox cannot act as a TLS proxy unless the IoT device is securely
provisioned with the middle-box's CA certificate as Explicit Trust Anchor
database entry to validate the server certificate. For example, the
provisioning can be done using an IoT device management tool (see

> 5. Section 4.2 said:
> "
>    If an IoT device is pre-configured to use
>    public DNS-over-(D)TLS or DNS-over-HTTPS servers, that middle-box
>    needs to act as a DNS-over-TLS or DNS-over-HTTPS proxy and replace
>    the esni_keys in the ESNI record with the middle box's esni_keys.
> "
> Same question is applicable to the quoted text? How do I make sure middle
> box is not a man in the middle attack?

Same as above.


> -Qin
> -----邮件原件-----
> 发件人: OPSAWG [] 代表 Joe Clarke (jclarke)
> 发送时间: 2020年9月2日 23:06
> 收件人: opsawg <>
> 主题: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
> Hello, opsawg.  This draft as underwent a number of revisions based on
> reviews and presentations at the last few IETF meetings.  The authors feel
> they have addressed the issues and concerns from the WG in their latest
> posted -05 revision.  As a reminder, this document describes how to use
> (D)TLS profile parameters with MUD to expose potential unauthorized
> software or malware on an endpoint.
> To that end, this serves as a two-week call for adoption for this work.
> Please reply with your support and/or comments by September 16, 2020.
> Thanks.
> Joe and Tianran
> _______________________________________________
> OPSAWG mailing list
> _______________________________________________
> OPSAWG mailing list