On Fri, Apr 24, 2015 at 10:27:58AM +0200, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi John, > > On 23/04/15 17:24, John Heidemann wrote: > > > > I took some time to read over > > draft-wijngaards-dnsop-confidentialdns-03 carefully and take some > > notes. > > > > Some comments below. Overall the ideas here are interesting and > > worthy of continued work, but the i-d does not seem ready for WG > > adoption in its current state. > > Thank you for your review, it looks like that text needs to be revised. > > > My biggest concern is comment (c) below: if I understand it > > correctly, the i-d seems an interaction between privacy choices for > > zone operators and connections that seems surprising. > > The "." name is because it is short. It is supposedly per-server. It > is true that for the 'authenticated' operation, key distribution uses > zone names (so it can be put in the DNS). But for the opportunistic > part, the name is irrelevant. Perhaps it should use class CH for that > exchange. > > Yes it is a key exchange, but not an established RFC; so it likely has > defects.
Some of the deflects: 1) Uses RSA key exchange, which is regarded as obsolete. The modern way is to use forward-secure (elliptic-curve) Diffie-Hellman key exchange with designated groups. Then hash the DH result and messages involved in key exchange into session keys. For authentication, either mix in results of type short-lived x long-lived (which tends to lead to deniable key exchange) or use signatures over important messages (not deniable). (TLS 1.3 drops support for RSA kex and non-designed group Diffie- Hellman, both were supported in TLS 1.2). 2) Seemingly uses unauthenticated encryption, which is a major no-no. Unless one is doing something exotic, just use standard-issue AEAD ciphers (RFC5116). With unauthenticated encryption, by playing with ciphertexts, one often can break the system in various ways, often leading to attackers successfully decrypting messages. 3) Uses CBC mode. That one has all sorts of weird issues. See above. -Ilari _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
