: > > > with almost no clear change on DNS protocol. > > Stop playing with words: if it requires a change in both client and server, it > *is* a change in the protocol (even if the DNS part is unmodified, which is, for > instance, the case with DNS-over-TLS-on-new-port). If it can be deployed > unilaterally by one party, it is not a change in the protocol.
Maybe there is misunderstanding of the definition of changes. Perhaps we need to come up with the unique the meaning of changes: I use the following definition. You might want to modify it. There are 3 different changes: - Big changes : completely new protocol than DNS --- I guess no of the current solution proposals were in this area... or if it is I cannot recall it. - medium changes: It uses the current DNS protocol but the implementation of that requires configuration changes on middle boxes as well as installation of the protocol on clients and server. It might be something like SSH that is the combination of different protocol that make one protocol but it has its own assigned port. If there is no unique assigned port then the problem might be the performance as the DNS server doesn't know which message on TLS port belongs to it and which one is for other purposes. You might say otherwise, but I would classify DNS over TLS in this category. - small changes: only the installation of that protocol (option) is enough. It uses the current DNS protocol. This is where I categorize CGA-TSIGe. > I don't see how encryption of DNS traffic could be done without a change in > the protocol. > I would be happy to explain to you in more detail. Of course I cannot cover all 50 pages of the draft here but try to make it short and only explain the main functions. --------------1-How a client receive the DNS information--------- Client receives the DNS information from an option in DHCP server or in an option of router advertisement in a secure way. Untrusted network: If the DHCP server is not trusted or DNS resolver is not trusted, then either the client can refer to the already trusted resolver list (I presumed that the implementation need to keep a short list of home resolvers or trusted resolvers). How to automatically fill this list might have different solution and not so easy. How a client understands whether this is trusted or not, one way can be based on receiving an invalid DNS IP address (in local range). If the user is professional, then the protocol should allow a user to manually set this value. Since the this protocol can securely authenticate the set value, it doesn't allow MITM. (please refer to draft for further information) ------------------2-How a client tells the DNS server that it uses cga-tsige---------- This has two options. Either using current available messages for key exchange without defining new messages. Or using the current DNS empty message only with having TSIG as an additional part and set the algorithm type to CGA-TSIGe. CGA-TSIGe is added in "Other DATA" of TSIG. (please refer to draft for more info) -------------3- Why DNS server exchange its keys with client and sign it---------------- 1- the client verifies the DNS server (authenticate) as it already received DNS server information in a secure way (like IP and hash of the key). 2- the client use this public key to encrypt only a random number (called shared secret or session key). Then the client can use this shared secret to encrypt the whole DNS message. -----------4- If the whole DNS message is encrypted, how the DNS server knows how to decrypt this---------- The DNS message is encapsulated to a new DNS message. After the DNS message is encypted using that shared secret, the client then add a new header to this DNS message and this encrypted message will be the body section of this new DNS message (please refer to the draft http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11#section-4.2.2.1. 1 specially step 4. for more information). In other word, CGA-TSIGe actually uses the whole encrypted section as one single question +-----+------+--------+ |Type |Length|Reserved| |1byte|1 byte| 1 byte | +---------------------+ | Header | | 12 bytes | +---------------------+ | Encrypted sections | | variable length | +---------------------+ | Additional Data | | variable length | +---------------------+ Figure 9 Encrypted DNS Query message Figure 9 of draft shows this encapsulation. When the DNS server receive such message, based on the header it can find additional section and when the algorithm type is CGA-TSIGe, then it first decrypt the secret key by its own private key (which is in the additional section) and then decrypt the whole message using the shared secret and a symmetric algorithm. All necessary information about symmetric algorithm can be found in additional section. This is the whole process. The main difference of this approach and DNS over TLS is how key exchange occurs and how they process the encryption. The similarity is that both need to use public key cryptography for session key encryption and shared key and a symmetric algorithms for better performance. The other difference might be the verification of DNS server. If there are other questions, I'll be happy to answer and cover them. Best, Hosnieh _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
