On Sat, Dec 8, 2018 at 12:46 PM Benno Overeinder <be...@nlnetlabs.nl> wrote:
> > For now, you are invited to review and add content to the wiki page: > https://trac.ietf.org/trac/dprive/wiki/DPriveStage2 > I unfortunately won't be able to attend today due to a prior conflict. After some discussing with some colleagues, a few topics that came up which I added to the wiki for discussion: *On signaling provisioning information: in operator considerations: * New record type for NSoverTLS? Use SRV? (Being able to use different servers for serving up DNS-over-{TCP,UDP} vs DNS-over-TLS responses may be valuable. * Signal secure transport details (DNS-over-TLS, DNS-over-QUIC, EncryptedSNI, etc), perhaps in an extensible manner? Minimize RTTs and reduce need for trials.* In particular, it would be highly desirable to not be required to couple the authoritative servers used for Secure-Transport responses to those used for conventional responses, plus there would ideally be a way to signal the transport (and transport parameters such as any future encrypted SNI) to be used to reduce the need for RTTs and opportunistic trials with fallback. Using SRV (or a more extensible SRV-like-format that could also include transport parameters) might be natural here and would also allow a way to signal when multiple authorities share a secure DNS authoritative service (to better allow for connection reuse). *On implementation details:* * * Reuse connection state * Minimize server-side state (eg, with session tickets) * Cache reuse vs. downgrade? Does the cache need to be partitioned? When can an in-cache answer retrieved via cleartext be served to a recursor via TLS?* On the first two, efficiently minimizing state (both client and server, but especially on the server) as well as reusing connections to minimize RTTs is likely to be critical to achieve performance, scale, and attack resilience. I suspect all of the protocol options come down to bootstrapping from set of asymmetric cryptographic primitives for clients and servers that share no history and constructing a shared symmetric key with which to encrypt-and-integrity-protect requests and responses. With additional variations on this to minimize asymmetric crypto operations, to minimize RTTs, and to securely memoize authenticated state (eg, with TLS session tickets). On the last of these, there's a trade-off on to what degree the cache can be shared between cleartext and encrypted requests and responses. In the HTTPS world, the general best-practice is to either not share cache or to only upgrade (eg, allow cleartext to use requests fetched over TLS, but not vice-versa). Even this is not always operationally viable. Given the presence of DNSSEC, some relaxation of this to allow more cache sharing may be possible. (There may be side-channel attacks exposed, but these may be possible regardless as long as any caching is performed.) Erik
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
