[ksk-rollover] IoT devices and KSK rollover

[Fred Baker]

On Jun 12, 2019, at 6:07 PM, Michael Richardson <mcr at sandelman.ca> wrote:
> But, if you already have TLS code in the device, then maybe it's cheaper
> to do this instead of DNSSEC.

That's apples and orangutans. TLS secures the channel (chain of custody), DNSSEC secures the data regardless of the channel (correctness of the data). You know that the data came from IANA and has not been screwed with in the process through DNSSEC. You know that the guys that handed it to you is your DOH server (and, potentially, the fact that he handed it to you) by TLS. If you only depend on TLS, the content might have changed dramatically.

That, BTW, is the argument for RPKI as opposed to TLS or other hash/signature/whatever in BGP.

I can tell you that the Root Server System delivers the IANA database, speaking as a root server operator and the co-chair of that committee in ICANN. If I can say this without appearing to cast aspersions, I don't know that for the DOH operators as a class. For example, and again I don't intend to cast aspersions, the YETI project (RFC 8483) downloads the root zone and then re-signs it. Apart from direct comparison, I'm not sure I have a way to know that an alternate root delivers the same data - all of the RRs, only the RRs, and each individually unchanged - apart from the IANA signature. A DOH service is essentially the same - I can trust it if and only if I'm implementing DNSSEC *and* the record I receive, by whatever channel, is signed by the Root Zone Maintainer.

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190613/4f4f917d/signature.asc>