Subject: [dns-privacy] DPRIVE Phase 2 Milestones and Requirements for WG Virtual Meeting 2018-12-10

From: Benno Overeinder <[email-masked]>
Date: Sat, 8 Dec 2018 18:46:44 +0100

[Same email, different header to assure email did not disappear in
original thread.  Sorry for spamming.]

Hi all,

On 28/11/2018 15:19, Brian Haberman wrote:
>      The main focus of this interim will be item #3. Benno & Alex have
> volunteered to collect all the issues and requirements that have been
> raised during our mailing list discussions into a draft that will be the
> basis of that discussion.

As Brian mentioned in previous emails, Alex, Willem and I have collected
issues that have been discussed on the mailing list and added some
issues ourselves (during a session last week).

We decided to use the DPRIVE wiki instead of writing a draft though.
The main goal of the first draft is to collect and organise the various
perspectives and requirements on DPRIVE phase 2.  We are happy to write
a draft after the DPRIVE WG Virtual Meeting.

For now, you are invited to review and add content to the wiki page:
https://trac.ietf.org/trac/dprive/wiki/DPriveStage2

Best regards,

Alex, Willem and Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Erik Nygren <[email-masked]>
Date: Mon, 10 Dec 2018 09:37:14 -0500

> 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

---

From: Loganaden Velvindron <[email-masked]>
Date: Mon, 10 Dec 2018 18:45:06 +0400

> https://trac.ietf.org/trac/dprive/wiki/DPriveStage2

May I suggest adding this one:

draft-ietf-dprive-bcp-op

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 Dec 2018 15:50:19 +0000

On Dec 10, 2018, at 6:37 AM, Erik Nygren <[email-masked]> wrote:
> After some discussing with some colleagues, a few topics that came up which I added to the wiki for discussion:

The changes you added all assumed that TLS was going to be the protocol chosen. I have edited (hopefully politely) to indicate that the WG might still choose a connectionless protocol such as sending COSE-based messages.

--Paul Hoffman

---

From: Benno Overeinder <[email-masked]>
Date: Mon, 10 Dec 2018 16:59:08 +0100

Thanks all for your input.

As a reminder, the virtual call is via webex:

https://ietf.webex.com/meet/dprive

-- Benno