On March 5, 2022 5:27:48 PM EST, Michael Richardson <[email protected]> wrote: > >Eric Rescorla <[email protected]> wrote: > > I provided some comments at the end of my review. Briefly, I have doubts > > that this > > is the best technical approach and so I think if we are to work on this > > problem > > we should start by working out the problem statement and requirements > first. > >I would agree with you. > >In particular, I think that UPnP or PCP, in combination with some kind >of dynamic DNS infrastructure, could do everything SNIF does, and do it in a >far more decentralized fashion. > >So what is it that SNIF does that is truly different?
I had a discussion with Eric about it. SNIF can work for an IoT device behind NAT or firewall through the relay. For IoT devices that have a clean static IP it's possible to use DDNS to directly connect to the device instead of the relay (not described in my draft but is fairly easy to implement through a peripheral process). Regarding the certs, a CA, for example Let's Encrypt, operates in terms of a 'Registered Domain', e.g. something.com, that you purchase from a TLD. Registered domains are not free, hence having a unique registered domain per an IoT device is not affordable - even if it's $2/yr nobody's going to eat that cost, and very few IoT end users will be willing to set up their own additional billing. Therefore, hostnames for individual IoT devices should be subdomains of a certain registered domain. Since a CA sets limits on API calls within each registered domain, if you allow IoT devices to randomly interact with the CA you set yourself on a path to a DoS. So, having a CA proxy that maintains control over the DNS zone and interacts with the CA (without having access to anybody's private keys) while enforcing anti-abuse policies sounds like a good solution. As for the security risk, it lies in the CA challenge. Having a DDNS server for a zone poses same risk as a CA proxy that has sole control over a DNS zone, with additional headaches and risks of DDNS authentication for each IoT device. If anybody disagrees or has something to add - please chime in. > > >> Have the SECDISPATCH chairs put it on the > >> agenda, > > > I think putting it on the SECDISPATCH agenda would be appropriate > >Good. > > >> or is there any agreement that maybe IOTOPS should dispatch it? > > > I think that would be a bad idea. There's nothing really IoT-specific > here. > >There is often nothing IoT specific about many things. >There is however a community of people who understand the set of tradeoff in >deploying systems at large scale that have no human at the helm. > >-- >Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
