On Thu, Oct 26, 2023 at 05:49:08PM -0400, Michael Richardson wrote:
> > Sure, but that DNSSEC issue equally applies to TLS proxies, right ?
> > DNSSEC is not mentioned in the docs paragraphs discussing TLS.
>
> TLS proxies do not change/break DNS(SEC).
> They "attack" at the TCP layer (in the same way NAT44 does), forcing traffic
> through their engine.
If they do, sure. I don't think that there is an actual definition that
says so, and i thought i've seen different ones as well.
> The TLS validation step is really a separate thing, and with what you
> suggested, an IP address per destination, and a circuit-layer forward proxy,
> then the device would actually be connected (at layer-4) to the real target.
> So whatever TLS certificate validation they do would just continue to work.
That was the idea. Obvious the experience from BRSKI proxy popped up reading
this
thread..
> > Of course, one could always extend MUD to explicitly allow clients
> > to look for local-domain domain names to explicitly support TCP/UDP or
> TLS
> > proxies in case such proxies are desired. TLS proxies of course still
> > being a highly desirable option to support (likely independent of this
> draft),
> > to allow the operator of the MUD devices to actually inspect the traffic
> > between te devices the operator owns and their cloud services.
>
> I don't really understand what you are saying here.
> Yes, some people would like to inspect traffic from their IoT devices.
> Others see that as a serious risk to the device, and specifically do not want
> the liability. Even enterprises that do forced TLS inspection are apparently
> recognizing that they MUST exempt banking and health traffic; or face serious
> legal consequences.
Once personal devices of factory floor workers start to have MUD profiles,
we can start worrying about privacy right violations in TLS proxies in the
context of MUD.
I was thinking about devices for which those don't apply.
For industrial devices, especially those coming from all type of international
vendors
it could easily start becoming a simple security requirement that the operator
of
a factory installation must be able to verify the traffic to that (foreign)
manufacturers
cloud devices. And use of standardized encoding protocols/semantics wouldn't
make that
a big deal for a good application layer firewall. And provisioning LDevID so the
private key of the industrial devices can be shared with the installation
firewall is certainly
possible with some enrollment protocols.
Aka: I think the actual TLS proxy case should not be dismissed as the draft
currently
does. It's certainly not something one may want to recommend solely to solve
the DNS
issue, but if it's required for security of the opeational deployment, then MUD
should
not stand in its way. For example, if the TLS proxy just intercepts at L4 as you
say, then it seems it should actually work pretty well with SNI: The firewall
will act as TLS proxy, read the SNI, validate it, and break the connection if
not allowed by MUD.
Cheers
Toerless
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
