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

[Ben Schwartz <[e-mail]>]

Thanks for addressing these issues, Tiru.  To confirm that this document
now reflects IETF consensus, I think it would be logical to send it to the
TLS WG (noting those changes) and confirm that it now has consensus there.

On Mon, Jan 9, 2023 at 1:07 AM tirumal reddy <[e-mail]> wrote:

> Hi Ben,
>
> I re-looked into the discussion in the TLS WG mailing list and we have
> addressed all the comments raised by the WG members.
>
> The issues raised by the TLS WG and addressed in the draft are:
>
> (a) We added Section 6 to explain the rules to processing the MUD (D)TLS
> rules to handle ossification and updated Section 10 to enable faster update
> to the YANG module.
> (b) Updates to the draft that the YANG module must not include GREASE
> values (see Section 5).
> (c) Privacy issues related to not revealing the MUD URL to an attacker is
> discussed in Section 9.
>
> Please let us know if you see any other pending issues.
>
> Cheers,
> -Tiru
>
> On Fri, 6 Jan 2023 at 21:43, Ben Schwartz <[e-mail]> wrote:
>
>> 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 <
>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
>>>
>>