W dniu 22.10.2015 o 15:04, Wiley, Glen pisze: > On 10/22/15, 8:18 AM, "Witold Kręcicki" <[email protected]> wrote: > > >> W dniu 22.10.2015 o 13:44, Wiley, Glen pisze: >>> 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. >> Because that would require an unencrypted query to the zone NS to get >> the zone key - and that would be a huge leak of information (as an >> attacker would know that a victim is looking for something in >> wikileaks.org, probably www.wikileaks.org). I know that putting the keys >> at the delegation point is going to be much harder to implement in real >> world but as an alternative is compromising privacy - it's the only >> proper way. > > This is a great opportunity to not let the best become the enemy of better. > The parent could be a preferred location rather than the only location. That is an option, but I'm afraid that if this becomes an option then no operator will allow putting NSK at delegation point...
> Passive monitoring would see a query go to the NS IP of the zone in > question > anyway so you don't really loose much privacy by publishing the key at the > NS owner label. You are still able to encrypt queries that include a > delegation. In most cases NSes are shared (I always wanted to use wikileaks.org, but it's a bad example here ;) ) so information that a specific IP is queried is only revealing that a victim might be querying one of the domains that are hosted on a specific NS (and attacker usually doesn't have the full list). Witold Krecicki _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
