Stephane, At 2016-12-13 16:41:33 +0100 Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
> On Tue, Dec 13, 2016 at 03:46:25PM +0100, > Shane Kerr <sh...@time-travellers.org> wrote > a message of 120 lines which said: > > > I think that TLS may be more painful in the resolver-to-auth case, > > as TCP Fast Open will be generally less useful, right? > > Same thing (even worse) for persistent TCP connections. > > But the problem is made less serious by the huge concentration of > authoritative name servers (this concentration is a bad thing, but it > helps for clients who maintain per-server state, which would be the > case with TCP Fast Open). Among the Alexa top 100k, only 24 k servers > <https://blog.imirhil.fr/2015/02/18/vie-privee-dns.html> I suspect among the top 1M there is probably even more concentration, given that companies are more likely to outsource hosting (both DNS and web). > > AIUI the draft, if we want to use DNS the problem is that we want to > > know how to encrypt a session to a name server, but we can't look up > > anything about the name server in the DNS because we don't yet know > > how to encrypt a session to the name server. > > I disagree. We can look up without keys. It just has to be without > privacy. See for instance the discussion on > draft-ietf-dprive-dtls-and-tls-profiles, specially > <https://mailarchive.ietf.org/arch/msg/dns-privacy/U9bGDAOReP_zYc4tPZY4AdWc2eM> So basically you are advocating a model where meta-data (specifically lookups of NS records and their associated A/AAAA records) is public and other data is private? It's a "better than nothing" solution, but I'm going to push for a complete solution if it is not too complex and/or expensive. > > * keys must be shared across administrative boundaries (that is, if > > I use Dyn and FreeDNS for hosting, then both hosters can > > impersonate the other or decrypt traffic to the other) > > This is for me a stopper. Thinking about this a little more, there is no reason that multiple authentication tokens could not be published. So Dyn could have token 1234 and FreeDNS have token 5678. When the Dyn servers present token 1234 a resolver could see that it is on the list of acceptable tokens. Presumably this kind of logic would be necessary for key rollovers, just like in the rest of DNSSEC, right? Cheers, -- Shane
pgpmCYqQQMzLC.pgp
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
