Hi Christian, Thanks for sharing your opinion about current approaches and also CGA-TSIG.
> If we do change the client and resolver, a number of alternatives can > be used, such as: > > * Use the same trick as CGA but encode the hash of the certificate as a > name part, e.g. "AF4563ED0B561.example.com". This is probably easier to > use than CGA, because names are less restricted than addresses. True, This is to some extend prevents exposing information and I think this is how NSEC3 works. But do you think it is applicable for resolver scenario. I think in this case we have two scenarios 1- client sends a plain text to resolver, resolver can respond to client with hashing the whole query. IN other words the whole www.example.com can be hashed and resolver can respond to the client by sending abcabcabcabc. In this case, if people here are worry about plain text, then the plain text is already exposed in client's request. 2- client cannot hash all its query. This is because the resolver does not know then what is the content of its query so that it can ask the right authoritative server. Therefore only the first scenario can happen that it still might expose information. > * Use Secure DNS, or DANE, to verify the resolver certificate. > Both of these approaches have the same property of reusing an existing > provisioning channel. The DANE approach is probably easier to manage, > because both the "hash in the address" and "hash in the name" > approaches have a hard time dealing with certificate renewal. DANE might be ideal for some scenarios but I think for this scenario where we are talking about last miles of the internet (end users), the pre-configuration of clients with trusted anchor/s for certain domain might not allow unknown nodes to use this service or administrative overheads. Because a node might also move from one network to another. This is why I thought CGA-TSIG can be helpful in such scenarios. I again do not claim that it is the best approach but I think it reduces many required configuration. About generating new keys (dealing with certificate renewal), I also thought about an approach and how client or server can inform the other communicating party about the new keys. because in my proposal I tried to considered all possible situation such as dynamic environment where nodes need to change their IP address or their keys. However, I guess for DNS server, changing keys might be a rare case. In other word, what I understands from DANE, clients needs to be configured with the list of trusted anchors for certain domains. While CGA-TSIG need only the IP address of resolver or maximum the hash of public key and IP address (for IPv4). This IP address can be received either from Secure RA or from protected DHCP server or even set manually. Thanks, Best, Hosnieh _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
