Toerless Eckert <[email protected]> wrote: >> > If this geofenced is what i think, then i don't believe it is a valid >> > argument: >> >> > The draft outlines how TLS proxying does not work with 1.3 >> > anymore. However, TCP and UDP proxying would still work, as long as >> > servers do not try to deduce anything from the IP address of the >> > connecting clinet (or vice versa), but only worry about the >> > cryptographic authentication. >> >> > In result, a well working strategy for MUD enforcement points would be >> > to act as TCP/UDP proxies for all the domain names known from MUD >> > files. In return of course, they have to be the DNS servers inquired. >> >> So, the idea is to lie in DNS for all the names in the MUD file, point at >> some RFC1918/20 block (or trivially a single IPv6/64). Then each end point >> is then proxied at the circuit layer to the real destination. >> >> This will trivially break if a device turns on DNSSEC, but otherwise, it >> seems like a reasonable way to implement.
> 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.
> And MUD devices with TA for their cloud services would arguably not just
> believe wrong DNS information when their TLS peer don't provide the right
> credentials, and hopefully those are not just WebPKI anyhow. Aka: not sure
> if DNSSEC is relevant.
They could well enable DNSSEC for name resolution.
(An IoT device with RPI4 inside, using systemd would do that today.
I am working on a project <rightnow> that uses such things as displays in a
kiosk mode, and a MUD file would be a good idea)
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.
> 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.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
