In my view we need to consider different privacy issues in the stub-resolver and resolver-authoritative interactions.
In the stub-resolver interaction the primary objective is to encrypt requests and responses without impacting latency. For a heavily trafficked resolver, the resolver-authoritative interaction can be addressed with caching and by pre-fetching the bulk of the requests. But this approach does not work so well for the lightly trafficked resolver and especially not a local resolver deployed in a home network. As a result, while I am focusing on the stub-resolver interaction, the resolver-authoritative interaction also needs to be considered in a solution. It might well be that the same approach would be applicable to secure the resolver-authoritative interaction but I have not considered that in depth at this point. Any approach using encryption needs to consider three parts 1) Discovery that the option is supported by the server to support opportunistic upgrade. 2) Distribution of a shared symmetric key 3) Formatting encrypted requests and replies. The first and the last are straightforward: A server that supports the option simply advertises it as an EDNS code. If additional information is required this can be supplied in new resource records. Alternatively, given that configuring DNS servers is a highly unsatisfactory process today, we might well want to use legacy DNS as a mechanism for bootstrapping the selection of a trustworthy DNS resolution service. So Alice might configure her home systems by selecting the 'example.com' DNS service provider on her browser, or alternatively in a DNS proxy built into her home network gateway device. The last part, formatting is pretty simple as well. We have a shared symmetric key between the client and server. Since we don't want to expose the key on the wire we must tell the server which key to use by means of a key identifier in the request. We also need to provide some mechanism to allow the client to work out which key to apply to responses. The shared secret must not be shared widely to avoid disclosure, this typically means that it should be unique to one client/server instance. We expect that most services would choose to avoid the need to maintain a database of id/key mappings by using the 'encrypt the key in an opaque identifier' trick used in Kerberos and widely employed in cookie type schemes. We do not and should not attempt to standardize the format of the identifier however as only the server side of the communication needs to agree on the format. Since we have a shared secret, we can and should add an authentication check so that the request can be matched to the response and prevent response spoofing attacks. The cost is negligible and provides protection even when DNSSEC is available. In particular consider attacks where a MITM is modifying DNSSEC signatures inside the encrypted packets. Without an independent integrity check on the response, a client has no way to distinguish this from an untrustworthy resolver. Given the number of bits required, the simplest approach would be to create a new QCode for an 'encrypted query' and encode the request in the request label. Note that since both the client and the server have to be aware of the new protocol we can make more radical changes if desired. For example, using the multiple requests feature supported in the protocol but currently unusable as clients don't support it. The complicated part of the protocol then is how we establish the shared secret. We do have some important constraints though. The first is latency, we can't afford public key operations on every request. Even if we could use exotic public key crypto to reduce latency to acceptable bounds we will be exposed to a Denial of Service vulnerability as even the cheapest public key crypto scheme is more CPU intensive than sending a UDP request. This means that we need to do the key exchange out of band with respect to the DNS query. Which fits perfectly with a selected resolver application or a highly trafficked authoritative server. The second constraint is Denial of Service vulnerability. A server cannot afford to perform a public key operation without some level of proof that the source IP address is legitimate. Which means looking at an IP round trip first. A third concern is whether we care about the resolver building a profile of the user across requests. This is a very hard problem which requires us to perform a separate public key agreement operation each time we wish to 'insulate' one set of behavior from another. For example, a resolver might choose to encode the identity of the user in the private keys it assigns. Making the behavior of the resolver robustly unlinkable is very hard. It may also be futile if the only viable business model for offering public resolution services turns out to be advertising based. Once established, a shared secret is in principle no less secure than public key for authentication/encryption. The volumes of data to be encrypted are insignificant compared to a 128 bit key space. So we can and should consider the key setup to be a once-and-forget operation rather than something to repeat every day or hour. Worst case we have to repeat our setup occasionally when administration of the service fails badly and we have to recover. These considerations make me look towards TLS rather than DTLS as a security layer. In WS-Connect, I rely on TLS to secure the key exchange. This si a JSON based HTTP/REST web service that has already been implemented for a very similar protocol: https://datatracker.ietf.org/doc/draft-hallambaker-wsconnect/ Relying on TLS is not best practice, I would prefer to do a secondary key exchange so that we are assured of security even if the TLS gets messed up. But remember that this is a one time fire and forget type operation. Using WS-Connect we establish a shared secret relationship with multiple hosts within a given service. There is also the option of the service telling the client that different protocols and/or transports are supported. In effect WS-Connect supports a Web Service level version of the SRV record and hands the client a kerberos-like ticket for each one. We could of course use GSSAPI for the same effect, but since these are inherently two party exchanges we don't need to standardize the ticket format. Depending on the specific use case we may or may not want to authenticate the client to the service. * If we are attempting to conceal the end-user's behavior from the resolver we obviously don't want to authenticate the end user! * If we are providing access to a split horizon DNS and don't want to have the extra chronic unreliability of every VPN it has been my immense displeasure to have inflicted on me, then of course we want to authenticate the client strongly and quite likely want to re-authenticate on a regular schedule. * If we are dealing with an embedded device like the coffee pot then we probably want to do a one time authentication to bind the device into the network. * If we are dealing with a paid service then we want to authenticate. WS-Connect already supports both the unauthenticated and authenticated client configurations. Preventing request linkage. Encrypting requests and responses prevents an attacker accessing the contents of the message but may leak information about the identity of the user to an observer. For example, Alice uses her laptop at two hotels, unless countermeasures are taken this could allow the hotels to link her two sessions. One solution to this is to issue a 'book' of access tickets rather than a single ticket. On making the initial connection, Alice is issues a book of 5 tickets. Each time her network connection context changes, her client automatically uses a different ticket. Each request contains a new ticket and encrypted private key to allow her to keep her book topped up. -- Website: http://hallambaker.com/
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
