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
