On 10/22/15, 8:18 AM, "Witold Kręcicki" <w...@isc.org> 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. 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. I disagree that it would offer a "huge" leak of information, in fact I would argue that you really don't disclose anything that would not already be disclosed since you have to talk to the NS IP. > >> 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. >This approach is mostly for recursive servers - and those as mostly >managed by owners of the net block. An alternative for recursive servers >is a hardcoded key in eg. /etc/resolv.conf. >The question if this should be a fallback for auth servers is open for >discussion, I've already heard voices that it's not a good idea and I'm >not insisting on it. > >> 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. >My goal was to allow two different keysets for a domain in case its >nameservers are operated by different entities, so that domain owner >doesn't have to share his keys with SNS (and so that a SNS can use small >amount of keys, and not different key for every domain it hosts), eg: > >example.com IN NS ns1.provider1.com >example.com IN NS ns2.provider1.com >example.com IN NS ns.provider2.com >example.com IN NSK ... *.provider1.com ... >example.com IN NSK ... *.provider2.com ... > > >> 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? >I'm open to propositions, I had an opinion that DNSENC is to similiar to >DNSSEC so I've changed the name to DNSCRYPT just to get a message that >it is already commonly used so I'm back to DNSENC. > >> 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. >Agree, that's an early version of draft and I was focused mostly on >describing the general idea, not getting into details. > > >Witold Kręcicki _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
