On 10/22/15, 9:15 AM, "Witold Kręcicki" <[email protected]> wrote:
>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... It is often the case that when a technology attempts to impose the best option rather than provide a bridge or progressive path to adoption that it may simply not be adopted. I would like to see your idea refined and tuned up so that it can move forward and I think it would be a shame to create this obstacle to adoption. > >> 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
