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

Hi Qin,

Thanks for the support and review. Please see line

On Mon, 7 Sep 2020 at 07:37, Qin Wu <bill.wu@huawei.com> 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
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-6

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

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

Cheers,
-Tiru

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