Toerless Eckert <t...@cs.fau.de> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg