On Aug 20, 2014, at 8:11 AM, Jacob Appelbaum <[email protected]> wrote:
>> The document is not going to list what a default policy should be. > > OK. > > Perhaps it would be useful to state assumptions about what a different > policy means? I have no idea what you mean, but I suspect you do. Proposed wording would be appreciated. > If a user manually configures a confidential server (and loads the > fingerprint or learns the key with DANE) - it is expected that an > implementation MUST fail closed? I think this is what happens when you > use the OpenDNS resolver with their crypto implementation. I don't > think it falls back to plaintext. It would be good to see their actual protocol design; it sounds like that is forthcoming. >>> I think a key thing is that we need a way to discover that an already >>> configured stub resolver supports this kind of confidentiality. When >>> the stub software updates, the resolver that is already configured >>> could be upgraded to use the privacy preserving path, for example. >> >> That would take an API. I really don't want to force that into this >> document, but as I said above, if you or someone wants to tackle the API >> question, I'm happy to point to it. >> > > Hrm - would it? Yes, it really would. > I think that we could just add something like "stub > resolvers SHOULD automatically request the following DANE record > foo.bar.baaz.keys.whatver to learn the key for their encrypted > resolver. Recursive resolvers supporting DNSSEC MUST verify that this > record is correctly signed." That would only work for security-aware, validating stub resolvers, which is currently a teeny minority of what is deployed. Further, that would also imply that the stub resolver is also recursive in order to find the DANE record; at that point, this protocol is not needed. > Does it need to be more complicated than that? Yes, unfortunately. A non-validating stub resolver that needs a key for the TLS server needs to get it out of band, I believe. I'm happy to hear other opinions though, because it would make getting all the way to authenticated encryption more likely. > I mean, we'd need to > agree on the record but I suppose there is a PTR record name that > would fit here, no? No, not yet. There is even less DNSSEC coverage in the reverse tree than there is for normal names. Updated draft with recent suggestions coming out soon. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
