W dniu 20.10.2015 o 10:19, Stephane Bortzmeyer pisze: > On Mon, Oct 19, 2015 at 09:58:41PM +0200, > Witold Kręcicki <[email protected]> wrote > a message of 28 lines which said: > >> I've just posted an updated version of Stateless DNS Encryption >> draft, it still has holes and unaswered questions but it's now >> almost implementable. > > Interesting, I think. > > The pros: simpler than TLS and may be less traffic (any actual sizing, > either in theory or by measurements? TLS has some overhead but DNSENC > requires sending a key with each request. You give the numbers for > DNSENC but not for TLS).
For a single message DNSoDTLS has a theoretical 13 byte overhead for header + cipher/authentication overhead. Unfortunately I haven't seen a complete analysis of a real-world DNSoDTLS overhead, and I'm not that familiar with TLS to make any assumptions. DNSENC elimitates the need for first handshake, as the key for the server is given with the NS/DS records from the parent zone - this causes overhead on message size: for one key and ECC encryption - ~30 bytes for NSK RR + 300 bytes for RRSIG RR, but no additional round-trips. Someone with deeper knowledge of DNSoDTLS would have to give us actual numbers here. > The cons: DNS-over-TLS can be implemented as a simple transport, > irrelevant for the upper layers of the DNS server and client. DNSENC > requires the server to memorize the key while the request is pending > so you need to change the purely-DNS part of the server. True, but if you really don't want to touch the inner DNS part of your server then you may implement the encapsulation/decapsulation of packets in DNS as a 'transport' - if this 'transport' detects that a packet is a DNSENC packet (and there is a clear way to do it) it decapsulates it, decrypts it, and sends it to the lower layer. > The neutrals: it is not TLS. I let you decided if it's a pro or a > con. It requires DNSSEC. Any system that is supposed to provide privacy of communication requires a method for peer identification/validation. TLS uses PKI/CA system, I believe that since we have a system for it built into DNS it's obvious that we should use it to validate our peer and not use an external mechanism. > Technical issues: > > "NSK RRsets MUST NOT appear at a zone's apex." And then an example > with NSK at the apex... I wasn't clear enough on that - that example shows records at the delegation point, NSK records are served the same way as DS records in DNSSEC. Witold Krecicki _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
