<div dir="ltr">Thank you Eliot and Michael for this thoughtful discussion and sharing the draft. I agree with you regarding the security issue with  shared cloud infrastructure and DNS. However on IoT device side,  do you think, a hardware based authentication  (e.g., quantum tunnelling  - <a href="https://www.cryptoquantique.com/solution">https://www.cryptoquantique.com/solution</a> ) may solve some of these issues?<div><br></div><div>Best regards, </div><div>Poonam</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020 at 5:47 PM Michael Richardson <<a href="mailto:mcr%2Bietf@sandelman.ca">mcr+ietf@sandelman.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Eliot Lear <<a href="mailto:lear@lear.ch" target="_blank">lear@lear.ch</a>> wrote:<br>
    > Thanks.  The concern here is that the device could choose to identify as<br>
    > something else through a set of false communications.  It is indeed an<br>
    > interesting area of research.  I am not saying there is nothing to be<br>
    > done, but it is something that requires careful consideration as we aim<br>
    > toward automating policy.  I fear in particular that the cloud makes<br>
    > this quite a bit harder, and IOT manufacturer use of their own DNS<br>
    > infrastructure will make it yet more difficult, because we are all using<br>
    > the same cloud infra.<br>
<br>
Manufacturers SHOULD avoid using their own DNS infrastructure in my opinion.<br>
<br>
        Operational Considerations for use of DNS in IoT devices<br>
         draft-richardson-opsawg-mud-iot-dns-considerations-01<br>
<br>
Abstract<br>
<br>
   This document details concerns about how Internet of Things devices<br>
   use IP addresses and DNS names.  The issue becomes acute as network<br>
   operators begin deploying RFC8520 Manufacturer Usage Description<br>
   (MUD) definitions to control device access.<br>
<br>
   This document explains the problem through a series of examples of<br>
   what can go wrong, and then provides some advice on how a device<br>
   manufacturer can best make deal with these issues.  The<br>
   recommendations have an impact upon device and network protocol<br>
   design.<br>
<br>
..co-authors, reviews, pull-requests and comments sought.<br>
<br>
{I'm annoyed that the DNSOP group declined to define "QuadX" as a term in<br>
ietf-dnsop-terminology-ter. Actually, I don't care what it's called, as along<br>
as I have a term for such public recursive services}<br>
<br>
--<br>
Michael Richardson <<a href="mailto:mcr%2BIETF@sandelman.ca" target="_blank">mcr+IETF@sandelman.ca</a>>, Sandelman Software Works<br>
 -= IPv6 IoT consulting =-<br>
<br>
<br>
<br>
_______________________________________________<br>
iot-wg mailing list<br>
<a href="mailto:iot-wg@ripe.net" target="_blank">iot-wg@ripe.net</a><br>
<a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a><br>
</blockquote></div>