Hi, Please excuse my potentially uniformed comment, but I think that DANE and DNSSEC try to solve the autheniticity problem (i.e I am talking to a valid auth NS).
The privacy discussion is about not allowing trivial mass surveillance. Thus, I would have thought that any reasonable encryption is good. E.g opportunitistic, CA, OpenPG, ... to the widest possible extent. The two need to be combined for AFXR / IFXR as the secondary server needs to be sure about the identity of the master (data source). It would also be important for caching resolvers who wish to pass on this degree of assurance to their clients. This should be a choice. People may wish to prioritise privacy over authenticity. (Personally, I would like both, but I am not everyone). End point clients who are directly querying auth NS's (which we hope is a relatively rare thing) may not care so much about the authenticity of the authoritative NS but do care about privacy and so hope for opportunistic encryption. To summarise: there are two issues, authenticity and privacy, and we should where possible allow for the greatest flexibility in the selection of mechanisms for either and their combination. Different client types (secondary servers, caching resolvers, end points) may have different priorities in what they care about and some combinations of authenticity and privacy may be easier than others for various parties and what is easier may vary. Regards, Hugo Connery -- Head of IT, DTU Environment, http://www.env.dtu.dk For data, integrity is critical, availability is convenience. Get both with git. ________________________________________ From: dns-privacy [[email protected]] on behalf of Shumon Huque [[email protected]] Sent: Saturday, 11 June 2016 18:35 To: [email protected] Subject: Re: [dns-privacy] Recharter discussion? (was DPRIVe Agenda requests for Berlin) On Fri, Jun 10, 2016 at 11:46 PM, Paul Wouters <[email protected]<mailto:[email protected]>> wrote: That assumes DNS lookups are for TLS...... I'm not sure I follow you Paul. This should work for any recursive to authority communication where TLS and DANE is available. To quickly sketch out what I was thinking (this is off the cuff and likely needs refinements/corrections; feel free to poke holes if you find any) ... Resolver signals dnssec_chain support in TLS handshake with a TLS equipped authoritative server. If server response provides the dnssec_chain, then perform DANE authentication of the server. Otherwise, authenticate the server in some other way (public CA system, static pre-configuration, or if allowed, just resort to unauthenticated TLS). Note: in this scheme, the TLSA record is associated with the zone name, not the NS record name, because a DNSSEC secured referral authenticates the zone name (not NS names provided in referral data). This means sharing a TLSA record set across all nameservers for a zone, but not necessarily TLS server credentials. The TLSA RRset could identify multiple distinct certificates or keys, if zone operators wanted compartmentalization of TLS credentials across servers (which might be important if multiple organizations are involved in running the servers). (It may be possible to securely authenticate DANE records at the NS names instead - but I haven't thought through that case yet. The zone name method seems simpler.) res-> . connect with TLS verify DANE auth chain for _853._tcp. TLSA authenticate server cert, pubkey, or raw pubkey query: www.example.org<http://www.example.org>. A response: signed referral to org. res->com. connect with TLS verify DANE auth chain for _853._tcp.org<http://tcp.org>. TLSA authenticate server cert, pubkey, or raw pubkey query: www.example.org<http://www.example.org>. A response: signed referral to example.org<http://example.org>. res->example.com<http://example.com>. connect with TLS verify DANE auth chain for _853._tcp.example.org<http://tcp.example.org>. TLSA authenticate server cert, pubkey, or raw pubkey query: www.example.org<http://www.example.org>. A response: answer: www.example.org<http://www.example.org>. A 1.2.3.4 DANE can be used selectively where available in this scheme. e.g. If the root servers don't do DANE (or TLS), the resolver obtaining a secure delegation could follow referrals and then attempt DANE authentication with the delegated zones, etc. A possible objection to using the TLS extension is that authoritative servers now have to do additional work querying for and maintaining the chain for their own DANE record. But that's small potatoes compared to the aggregate work of doing TLS. I'm not advocating this approach at this stage. Just sketching out a way that DANE might be used to provide authenticated TLS between resolver and authority servers. And obviously, other modes of authentication will need to be supported as well in the general case, because DNSSEC is not universally deployed. -- Shumon Huque _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
