On Mon, Mar 2, 2015 at 12:16 PM, Ilari Liusvaara < [email protected]> wrote:
> On Mon, Mar 02, 2015 at 11:28:54AM -0500, Phillip Hallam-Baker wrote: > > On Mon, Mar 2, 2015 at 9:00 AM, Ilari Liusvaara < > [email protected] > > > wrote: > > > > > > > > I would see the point of using UDP (which means increased complexity): > > > > > > No it does not. > > > > UDP is a lot simpler than any of the TCP proposals. > > > > * Fewer states > > * Smaller library > > * Fewer options > > - TCP orders the packets > Not very important. Most DNS query transactions can be fit into a single request/response message. I am proposing to keep the 'single request packet' and only loosen the 'single response packet' to permit up to 16 packets. If people think that multiple response packets are too much burden on the client then we could make this part an option even. > - TCP retransmits > Irrelevant, we already do this in DNS over UDP. If you don't get a response you ask the question again. > - TCP does error correction. > Irrelevant. First of all the error correction is not at all good. It is a short checksum without any crypto strength behind it. > - TCP deals with reflection. > Again, the weak protections in TCP are irrelevant because we are doing crypto and we should be looking for strong authentication of requests and responses. > Sure, one can do all the above with UDP-based protocols, but that means > extra code. > A lot less code than futzing about with the PKIX stack or the TLS stack. > DNS requires TCP already (as fallback for when packet limits get busted). I think that was always a horrid hack and it has never really worked at all well, has it? If people were happy doing DNS over TCP then most of the objections raised against DNSSEC would have gone away. > > TLS is a big complicated specification and the open source libraries are > in > > a woeful state. Take a look at the date the tutorial on the OpenSSL API > was > > written. > > There is UDP counterpart to TLS called DTLS. It is more complicated than > TLS (due to above factors). I don't recommend DTLS because it is designed to provide security for applications like VOIP where people really are reinventing TCP in UDP. > The expeditious approach to setting up a client-service binding is to > > leverage TLS. But that is separate from the DNS session transport > question > > and something that can be revisited later. > > I think (D)TLS is too complicated for stub<->recursive protocol (even if > profiled down). > Agree. That is not what I am proposing. > Also, can't deal with fast session startup until TLS 1.3 (which is still > quite complex and doesn't look even near finished, let alone DTLS 1.3). > Plus the scope of present challenge looks much smaller than TLS (e.g. no > client authentication, server recon is feasible, etc...). > TLS is a big, complicated stack. I want to limit exposure to it as much as possible. Just leverage it during a one time device binding operation and then not use it again > Of course, designing a new crypto protocol is pretty scary prospect > (I have seen one that has even simpler scope and looks totally messed > up). > If people don't think we can do crypto protocols then we should shut down DPRIV now. We are doing a new crypto protocol whatever we do. The question is how we put the parts together. The hard parts are key management and exchange and we don't need to reinvent that. Just reuse TLS for that part. The only parts we would be doing new are to write a new framing scheme which is a very well understood problem at this stage and optionally write a perfect forward secrecy option. On the PFS thing, the TLS exchange is botched anyway. adding in a PFS key should not downgrade security. Which is what happens if you use a WF 128 ephemeral after a WF256 master exchange.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
