On 20-Oct-2015 02:13 am, Witold Kręcicki <[email protected]> wrote: > > 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.
I count 16 bytes overhead for DTLS: 12 bytes for header, and typically 4 bytes for authentication tag. But Stephane was asking about TLS (not DTLS), and TLS doesn't have the 48-bit sequence number or 16-bit epoch (they are maintained internally with TLS, and not transmitted on the wire), so TLS should have 8 bytes overhead (if my math is right) and of course the TCP header is bigger than the UDP header. (Sorry, in a plane at the moment.) All those numbers are steady-state, after (D)TLS handshake. -d > 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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
