(caveat: I've yet to read the draft but will...)
On 07/03/2022 03:30, Jim Zubov wrote:
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 userswill be willing to set up their own additional billing.
The above IMO represents a pessimal view of where we want to go. Either these devices (in the home) will be a load of crap or not (my guess: most, but not all, will be crap). If there are lasting non-crap device types from different vendors then it'll be way better (also for vendors) that the householder has their own parent domain for the collective. Yes, getting there seems hard but that's where we ought go. (In reality, it's not that hard, it just requires a bit of focus on things beyond the current financial quarter.) Cheers, S.
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 appropriateGood.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_______________________________________________ Secdispatch mailinglist [email protected] https://www.ietf.org/mailman/listinfo/secdispatch
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
