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

From: Qin Wu <[email-masked]>
Date: Mon, 7 Sep 2020 02:07:39 +0000

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

-Qin
-----邮件原件-----
发件人: OPSAWG [mailto:[email-masked]] 代表 Joe Clarke (jclarke)
发送时间: 2020年9月2日 23:06
收件人: opsawg <[email-masked]>
主题: [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
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: tirumal reddy <[email-masked]>
Date: Sun, 20 Sep 2020 12:48:14 +0530

Hi Qin,

Thanks for the support and review. Please see line

On Mon, 7 Sep 2020 at 07:37, Qin Wu <[email-masked]> wrote:

> 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
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-6

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

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.

> 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
https://tools.ietf.org/html/draft-wang-tls-proxy-best-practice-00#section-4.1
).

> box is not a man in the middle attack?

Same as above.

Cheers,
-Tiru

> 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