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

[tirumal reddy <[e-mail]>]

Hi Michael,

Thanks for the review. Please see inline

On Sat, 18 Jan 2020 at 07:57, Michael Richardson <[e-mail]>
wrote:

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

No, the proposed mechanism will help identify the presence of unauthorized
software or malware on an IoT device.
MUD is not suitable for IoT devices with broad communication patterns and TLS
profile parameters can be used on such devices to permit intended TLS use
and block malicious TLS use.

Middleboxes act as TLS proxies in several deployments and the behavior of a
compliant TLS 1.3 proxy is discussed in Section 9.3 of
https://tools.ietf.org/html/rfc8446. Most importantly, network security
services have been using TLS profile parameters to successfully identify
malware and benign flows for several years (for example, see
https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/enterprise-network-security/nb-09-encrytd-traf-anlytcs-wp-cte-en.pdf
).

We have profiled several IoT devices in our lab and also observed TLS
profile parameters of thousands of malware flows. Our analysis helped
conclude intended TLS use can be permitted and malicious TLS can be blocked
(see
https://datatracker.ietf.org/meeting/106/materials/slides-106-opsawg-draft-reddy-opsawg-mud-tls
(slides
7 to 15) for more details).


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

Network security vendors offering firewalls/IPS to enterprise networks
already have the capability of performing TLS handshake inspection and
acting as a TLS proxy, they can leverage the proposed mechanism. Further,
firewalls acting as TLS proxy do several checks to identify MiTM attack.
For example, the most recent one is the Microsoft vulnerability to validate
certificates
https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF;
middle boxes can identify such MiTM attacks and protect endpoints.


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


Network security services have been using TLS profile parameters to
successfully identify malware and benign flows for several years. The data
features and ML models used by the security services is a public domain
information and also known to malware developers for a long time (for
example see https://arxiv.org/pdf/1607.01639.pdf).


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

Middle boxes from several security vendors acting as TLS proxies do keep up
with the updates to protocols (especially TLS) and strive be complaint TLS
middle boxes. You may want to look into the best practices for implementing
TLS proxies discussed in
https://tools.ietf.org/html/draft-wang-tls-proxy-best-practice-00.


>
> I don't think that section 4.1 needs to explain how BRSKI works.
>

Yes, the mechanism to bootstrap the IoT device with the middlebox's CA
certificate need not be discussed; will remove.


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

Yes, both security and privacy are required. Network security services
typically have a configuration option to act as a TLS proxy for endpoints.
It is up to the IT admin to determine whether the network security service
should terminate the TLS connection for a endpoint and destination address.
For example, IT administrator can configure firewall to bypass traffic
decryption
for a connection destined to a healthcare web service due to privacy
compliance requirements. Further, TLS proxies do protect the privacy of the
user and do not store PII data (See sections 4.9 and 4.10 in
https://tools.ietf.org/html/draft-wang-tls-proxy-best-practice-00#section-4.9
).

We will update the draft to clarify a middlebox can as a (D)TLS proxy for
the IoT devices managed by the IT team and the (D)TLS proxy must meet the
security and privacy requirements of the organization.


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

I don't get your comment. How will malware's command and control server
certificate be signed by the baked-in non-public trust anchor on the IoT
device ?


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

No, we are using MUD for IoT devices in our product
https://securehomeplatform.mcafee.com/ but as you already know MUD is not
suitable for IoT devices with broad communication pattern. TLS profile
parameters can be used on such devices to permit intended TLS use and block
malicious TLS use.


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

SPKI pin info can be configured on the IoT device to validate self-signed
server certificates or raw public keys (we  observed IoT devices
communicating with legitimate servers using self-signed certificates and
malware C&C servers also use self-signed certificates). SPKI pin info helps
to permit benign TLS flows using self-signed certificates and block malware
TLS flows using self-signed certificates.


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

Good point, will update.

Cheers,
-Tiru


>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>