On Thu, Nov 20, 2014 at 4:44 AM, Tony Finch <d...@dotat.at> wrote: > Phillip Hallam-Baker <i...@hallambaker.com> wrote: >> >> So lets say you want to connect to www.example.com via HTTP, the DNS >> queries might be: >> >> www.example.com ? A >> www.example.com ? AAAA >> _80._tcp.www.example.com ? TSLA >> _http._tcp.www.example.com ? SRV >> _http._tcp.www.example.com ? ESRV (A security policy record TBS) >> >> So the above would be five separate DNS protocol messages all framed >> in a single UDP packet. >> >> In most cases the results will fit in a single packet as well. >> >> Taking away the performance penalty for multiple record lookups would >> make a huge difference to the viability of proposals to extend DNS >> discovery services. > > If you already have a TCP connection open to your recursive server then > you can get the same performance with the current DNS protocol.
Yes, we established that already. That is the advantage of TLS over DTLS. The way I would score proposals objectively: 100%: Are connections guaranteed unless under active attack? MM: Are multiple messages per transaction supported? 1RT: What percentage of transactions are completed in a single round trip? PDoS: Is the query host required to perform pki processing on unauthenticated requests? QDoS: Prevent use of open resolver to relay a DoS attack on an authoritative server? State: Stateless server? We also have code criteria but those are pretty much subjective. We are all using TLS as a base. We all have some additional glue. DTLS support isn't universal and fast open is only supported on Linux. If you want to do mutual authentication then you are going to need more mechanism than bare TLS. The first one I consider to be a qualification requirement. DNS over TLS and DTLS can be configured to meet it but doing so requires some mechanism. So: DNS over TLS: MM - Yes 1RT - 65% PDoS - In loop PKI gated by cookie authentication QDoS - ? State - No DNS over DTLS MM - No 1RT - 97% [3% of real world network circumstances are bjorked] PDoS - In loop PKI gated by cookie authentication QDoS - ? State - Yes (but requires specific configuration) Private DNS MM - Yes 1RT - 97% PDoS - No in-loop PKI QDoS - All requests authenticated by MAC State - Server is stateless. Now granted this is my scorecard so its not surprising I win based on it. But I have been at this since long before there was a demand for confidentiality in DNS. And so I have spent quite a lot of time talking to various DNS people to find out what their requirements are. And I have accepted pretty much every requirement that has been suggested. The only requirements I don't address in the proposal on the table are the traffic analysis and anti-censorship requirements. And I am not putting the extensions to address those requirements on the table because they depend on steganography to an extent. In addition, the service connection module I am introducing can be used to simplify a lot of other Web Services. Certificate enrollment for example. That is important because even though TLS client auth is an excellent authentication mechanism, it isn't a solution to client auth without an automated certificate enrollment protocol. One final point. If people decide to adopt my draft then we can wrap up the DNS privacy work pretty quickly we can recharter and extend the scope to apply the same approach to time and other trusted protocols. While time does not necessarily need confidentiality, it does need authentication. And this is obviously meant to be since this group is called DPRIV, pronounced 'deprive'. Which means there has to be a successor DPRAVE, pronounced 'deprave'. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
