Ilari Liusvaara <[email protected]> writes: >> I'll update my position on WG adoption a bit: >> >> I support adopting DNS-over-TLS but urges the WG to adopt DNS-over-DTLS >> at the same time, and make consistency between them a requirement. >> Having both with different TLS-related security semantics would be a >> disaster. In fact, I would suggest that these two documents are merged >> into one. There is (or, rather, should be) more in common between these >> documents than what separates them. > > - Can one resume sessions across protocols (resume UDP session as TCP > session or vice versa)?
I don't think anyone has implemented something like that. > - Does DNS-over-DTLS need some sort of channel identifier in queries > (taking place of the 5-tuple)? To deal with things like client IP > address/portrange changes or client socket being dropped[1]. If I understand correctly, I don't believe DTLS has this, nor that it is something you want -- if something is messing with the traffic, you wan't detect/reject it not work around it. > - Also, whereas 53/TCP is surprisingly clean[2], 53/UDP has lots of bad > stuff going on, sometimes even with packets not destined to the middle- > boxes.[3][4] How bad is that problem? I have no idea. Isn't that part of the problem? > Also, some problems with (D)TLS: > - No length hiding: There is no defined mechanism for length hiding > (which is needed unless one can pad at DNS level). I think there > have been at least one proposal tho. (D)TLS has message padding to mitigate packet length analysis. Addmittedly, you can't pad more than 255 bytes. > - Complexity: Enormously complicated. TLS libraries are almost > invariably junk for one reason or another. > - Insecure configs: Most of TLS usage is insecure due to usage of > legacy junk. One could address this by aggressively profiling > down the usage. Sure, but you could say the same for DNS. I doubt that we can design a security protocol better than TLS here though. /Simon
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
