-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul,
So this is another solution, which I want out there in the solution space because it is stateless. And there are many things to consider ... Sending the qname as the zone name in plaintext is not a good idea. For hop-by-hop encryption there is no need to send more bytes, and it reveals the zone you are contacting in the clear - which is exactly what you are trying to hide. How is the ENCRYPT PAD record different from a TXT record in the sense of being able to add arbitrary data to a packet? I obviously did not want to use TXT. The reason it is added is that otherwise the packetsize becomes a highly deterministic value. We could make it be full of zeroes (or other deterministic content) ? On 11/28/2013 06:25 PM, Paul Wouters wrote: > On Thu, 28 Nov 2013, Glen Wiley wrote: > >>> Asking the LAN's resolver for a specific record (type ENCRYPT >>> to QNAME ".") seems a bit dangerous. This is of course >>> completely MITM-able, but I see no real other way to trust >>> something fundamentally untrustworthy. So that's okay. But I >>> fear too many of these queries might end up on AS112. I'd >>> rather see an EDNS advertisement. >> >> If the query is done via validated DNSSEC [...] > > You cannot do that. The DNS resolver DHCP gave you is 192.168.1.1. > How are you validating anything? how will you distinguish my rogue > 192.168.1.1 from the real starbucks 192.168.1.1? > > That's why the recursive case is so different from the > authoritative case. Well in both cases the idea is to use a completely-MITM-able query for ENCRYPT KEY to start the exchange. So that this technique can work in both problem spaces. At the end-client all you have is DHCP and somebody claims some IP address is your DNS. So the key lookup is just like that DHCP exchange, an initial exchange... EDNS advertisement. Well I agree a lot may end up being wasted queries. EDNS does not have a TTL, I want cachable resource records, and the plain new-type-lookup may find it slightly different to bypass end-client middleboxes than EDNS. But otherwise this is a DNS-packet-transportation issue. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSmE/vAAoJEJ9vHC1+BF+Npu4P/3HEfnftnSr5HKjgRIXvoUtm ko21WSnZcE+cJB3iqtJEF3TNnM+QRKYoNPs5Amkn3D+CGI4Olvb6w29jOc0NCH2B Bk36V03R+9/X6IIyU498LEjlebN0fIIx97O95fhCzzRdadh2f2/3vAt+VKYKHPuC R1UZWfrVS2AcZzuOedpFMhADQQvoeJjg4OYwlDxX/sZ0lJJTlUPSdRJMbX/m9SuM XCoMgXdk5Youb9ie4U/B5bNp9xSlJrdtTKwT/wUUM1JR1y7wD6IhjF1bjrfN3ZUO 6N2N9Pcyea9cTuthkeV1M5Yv7g06E3CnwwL3BXh3wKziop2Zgi13ZWtywviC1nea DYccAsUyfaNQubUoppm3gCIn8cTZPuFWHncTdgN34xuskrzegarGbKr8ugI/9oKh Ajr4eHGbcsXIuWhndp4qKITi06o5FM1yp71ReRrf9MEXnXILuSKE29Xmq62/lZpq uuVLu8Gq3IiHSqjFw+VlVV+YHyojituQscpx0JQz1pBt1L1eyTJpDfdrW7kieRHa Q7Sx5byfVAOYB84k2xW44aQWl5AVaqdabbrkAYoEa5IdXu3mAM8dDGEtEWC7sDCF KqEmxPpTwA8p3zp1Vmdzs9wk3ahn9mton4RwJeXTzwL1DsIxE0G/YJv3gXjuoNgU P3/HUxPhLaYQuNFjFZXr =HsWr -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
