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.
> 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
