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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Linda,

Thanks for the review. Please see inline 

On Fri, 18 Nov 2022 at 22:58, Linda Dunbar via Datatracker <noreply@xxxxxxxx> 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


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux