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
