This is an interesting idea, a few comments: 1. In section 2 it sounds as though you are suggesting that the new RR containing the encryption key needs to be published in the parent zone. Why not publish this as a RR at the apex of the zone with whose name servers you want to encrypt? The advantage to putting encryption keys in the zone rather than the parent is that you create less work for registrars who already seem to really struggle with providing a way to publish DS/DNSKEY records.
2. The fallback to reverse DNS takes an optimistic view of reverse DNS. Most hosting providers will not grant permission to customers to publish in the reverse DNS for net blocks that they manage. 3. I like the idea of leaving the DNS packets mostly in tact - I think this is more likely to survive transit through middle boxes that might want to do some simple packet inspection to see whether the DNS is being used for something other than DNS. This is in fact the same idea that Wouter Wijngaards and I proposed in the confidential DNS draft. 4. Section 3.1.1 specifies an applicable NS name. It is not clear to me why I would want this field. Wouldn't it be more consistent with the current mode of operation of the DNS to determine this using the DNS hierarchy? A zone operator would publish an NSK at the owner name for the NS to which it applies. 5. I would recommend choosing a different name for the new RR as Name Server Key could create confusion to folks learning about the various key records in the DNS. What about something like NSENCK - Name Server Encryption Key? 6. Failure modes could use some attention. It would be useful to distinguish cases where a decrypt fails due to a wrong key versus a format error, unsupported encryption scheme , etc. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 10/19/15, 3:58 PM, "Witold Kręcicki" <w...@isc.org> wrote: >Hi all, > >I've just posted an updated version of Stateless DNS Encryption draft, >it still has holes and unaswered questions but it's now almost >implementable. > >I'd really appreciate if the group could read and comment on it. > >Witold Kręcicki > > >A new version of I-D, draft-krecicki-dprive-dnsenc-01.txt >has been successfully submitted by Witold Krecicki and posted to the >IETF repository. > >Name: draft-krecicki-dprive-dnsenc >Revision: 01 >Title: Stateless DNS Encryption >Document date: 2015-10-19 >Group: Individual Submission >Pages: 15 >URL: >https://www.ietf.org/internet-drafts/draft-krecicki-dprive-dnsenc-01.txt >Status: >https://datatracker.ietf.org/doc/draft-krecicki-dprive-dnsenc/ >Htmlized: >https://tools.ietf.org/html/draft-krecicki-dprive-dnsenc-01 >Diff: >https://www.ietf.org/rfcdiff?url2=draft-krecicki-dprive-dnsenc-01 > >Abstract: > The DNS is the last common Internet protocol that has no encryption > scheme and therefore provides no privacy to the users. This document > proposes an extensible mechanism providing encryption of DNS queries > and responses with method for secure retrieval and verification of > validity of encryption keys. It is independent of the underlying > transport protocol. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > >_______________________________________________ >dns-privacy mailing list >dns-privacy@ietf.org >https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
