I think the draft is very unclear on this (DNSSEC) point - at least I don't find this statement about the ENCRYPT RR being signed by with the private key of example.com.
Anyway : a RRSIG RR holds the name of the domain that signed in clear text. Kind regards, Marc On Fri, Nov 29, 2013 at 10:40 AM, W.C.A. Wijngaards <wou...@nlnetlabs.nl>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Marc, > > In the draft it says to store the ENCRYPT RR in this case at > ns.example.com. It would then be signed with the ZSK DNSKEY for > example.com, with normal DNSSEC chain of trust. > > But again, the authenticated operation is not the main aim of this draft. > > Best regards, > Wouter > > On 11/29/2013 10:28 AM, Marc Lampo wrote: > > Hello, > > > > (a reaction on second paragraph of 4. Authenticated Operation, > > only) > > > > That paragraph states that the ENCRYPT RR can be signed by DNSSEC. > > However, I don't think is possible ! > > > > A signature is the hash of DNS-data-sent, encrypted with the > > private key. But in this case : private key of who ? !!! not the > > root-zone, I hope. ? from the domain one is about to sent a query > > for (but the whole idea is to hide that kind of information !) > > > > But since this encryption is really between a DNS client and the > > DNS server it is about to query, it should be the "private key of > > that DNS server". But that is not what DNSSEC is about. > > > > Hence, I think ENCRYPT RR's cannot be protected by DNSSEC. > > > > Kind regards, > > > > Marc > > > > > > On Thu, Nov 28, 2013 at 2:25 PM, W.C.A. Wijngaards > > <wou...@nlnetlabs.nl <mailto:wou...@nlnetlabs.nl>> wrote: > > > > Hi, > > > > I also heard that this is the place to discuss DNS privacy. > > > > This draft is a protocol, and represents an (interesting) point in > > the solution space. I would refer to Borzmeyer's draft and Koch's > > draft for problem space analysis. > > > > http://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-00 > > > > It supports opportunistic encryption, i.e. try to encrypt but > > fallback to insecure. This supports deployment immensely, because > > clean DNS paths are uncommon. > > > > It supports stateless operation. It uses UDP. > > > > It supports encryption for stub-to-cache and cache-to-authority. > > > > Best regards, Wouter > > > > _______________________________________________ DNSOP mailing list > > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSmGEgAAoJEJ9vHC1+BF+NM2MP/3eUycaHd5l3eywpaevDj9HX > z1E7b3+ebH/cLGMAR0KD940aYw7xYlDG/6b83hqeEVdQVxD7ga6VUcOPImbfOX7o > h8AwJif9mFsGaPCFwxMiaGnF/NmdPAt+C9KNB9fNuEKWIGZbNCDjms7KpC6FDTua > JJ6lPLnuuWCiIUEiKbsjOEl2sJ2y8XV48+jvKuYYXc3EOL2tF0+/BiclXSB7Jw3y > YZ9caUU24teNVWU6g24SflxX/WdPRdSGAGFLYmFc2NEWrrXVvhmpmVGl9le/W6Lc > /pycV+yQZEK7NXP1KrAx28GSjlaJ8duKAXgAk8zsw7bEiqMPpzzNx7fp9pkXGbRy > KoEKMiOdnZGnqhIAx4H32ookjWuMnZFGY2FeKL0D3YsR9AgkuVbc+ga7MODwg6JH > 62WADFn8DZCzbNOGIc7375FiVpogCZfPOP5BjrN1VTWL6r3jxAClWZABhQ+gEfCt > 34+cxl83FaznxkvhK5DBQoQQmVdcitKOywkKgTlCPAd+gXSJ7SzzxrlcC5Vz0Py5 > xoRYjPOnFC/Fz3rrLzhFomsISftKeIsvuCRlqsnd/FMzkqwxhUtZuKlUYEJs5qbF > kxv39xcDrAlbpyYvK5o14LKzto9+7/zpWI/js/0A1gWaq62mbpoq67J+UbgYCASk > Ilm/xu2QrnoGLsAS9R3q > =8SfA > -----END PGP SIGNATURE----- >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
