Re: [OPSAWG] New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

[Michael Richardson <[e-mail]>]

tirumal reddy <[e-mail]> wrote:
    > This revision
    > https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02 updates the
    > draft to discuss privacy enhancing technologies and evasion techniques
    > used by malware, visibility into TLS 1.3 parameters and how certain
    > types of malware can be blocked without acting as a (D)TLS 1.3 proxy.

    > As a reminder, this draft extends Manufacturer Usage Description (MUD)
    > to incorporate (D)TLS profile parameters. This allows a network
    > element to identify unexpected (D)TLS usage, which can indicate the
    > presence of unauthorized software or malware on an endpoint.

I have read opsawg-mud-tls, and I am in general very very reluctant to
provide detailed instructions on doing innovation kill intrusive DPI.
I think that it will ultimately not result in any improvements to network
security.

I see two advantages of this work, which mitigates my concern slightly.
(but, only slightly)
   1) if it's gonna get done by IDS vendors, then IoT device manufacturers
      might as well provide a way to help them *get it right*
   2) it seems that manufacturers might be able to say, "HANDS OFF"
      to IDS systems. (perhaps avoiding use of more colourful language)

The document says:
   In other words, 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.  Further, the malware's command and control server
   certificates need to be signed by the same certifying authorities
   trusted by the IoT devices.  Typically, IoT devices have an
   infrastructure that supports a rapid deployment of updates, and
   malware agents will have a near-impossible task of similarly
   deploying updates and continuing to mimic the TLS behavior of the IoT
   device it has infected.

It seems to me that malware will know exactly, thanks to this extension how
to perfectly impersonate the device.  Given that TLS1.3 makes so many of the
characteristics of the implementation less visible, it seems that this is
just a dangerous arms race.  As border MUD gateways get more detailed in the
way they examine things, the ability to innovate in TLS will simply diminish.
It is my understand that we already had to do the TLS 1.3 version negotiation
differently thanks to middle boxes because of such nonsense.

I don't think that section 4.1 needs to explain how BRSKI works.
In any case, it's not BRSKI that matters, but EST(RFC7030)'s /cacerts.
I see that it's probably difficult to get to RFC7030 just to run /cacerts,
but if BRSKI is being used already.  {If this gets better IoT onboarding into
Enterprises.... well. What a Faustian bargin...}

I believe that attempting to auto-configure a TLS 1.3 MITM proxy using EST is
a really bad idea.  Devices that are willing to fall prey to such a
"friendly-fire" attack would seem to be broken to me, period.
I suspect that US HIPAA legislation and probably European GDRP might well
make such a MITM a serious privacy violation.  Any medical device that communicates
patient data that could be spoofed like this might be considered to be violating.

Additional, it is entirely reasonable (perhaps, given MITM attacks!) for an IoT
device manufacturer to "call home" using a baked in, non-public, trust
anchor. Such a situation would be indiguishable from malware calling C&C
using a baked-in trust anchor.
I would certainly want to do this for firmware updates.

Given that MUD can clearly control where connections are made, it seems to
me that much of this effort is a mis-guided relic of pre-MUD DPI IDS systems.

I suggest that section 4.2 reference draft-richardson-opsawg-mud-iot-dns-considerations-01.

I didn't understand the purpose of the SPKI pin info mentioned in section 5.
I suggest that you remove details from this overview section, and list just
the high-level and leave the details for a section on each part.

As far as I can tell from the YANG module and the example, the stated TLS
profile appears to apply to any/all TLS traffic coming from the device.
I would have expected it to be expressed on a per-port outgoing/incoming basis.
(Perhaps defining the profile(s) once and then re-using it)

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-