Subject: [DNSOP] some random dnse-triggered thoughts

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2014 18:15:37 +0000

I have not reviewed all these drafts thoroughly, since I am a slacker, and so what follows is mainly a reaction to presentations and not a detailed reading of the text. So, in no particular order (hence numbering):

8. draft-hzhwm-start-tls-for-dns-00, TO not protected

It seems like a potential problem that the TO bit is not protected. A middlebox could strip TO in one or both directions and prevent TLS from ever being established. To both ends of the transaction, this seems indistinguishable from the case where the other end just doesn't support TO. A secure assertion around TO seems necessary. See 3b(ii).

3. draft-hzhwm-start-tls-for-dns-00, address to name mapping not 1:1

It seems like the nameserver name needs to correspond to some data in a certificate in order to confirm that the certificate being presented by the other end is authentic. It's possible in the DNS for many nameserver names (NS RDATA) to correspond to the same physical server. How does a server receiving a query know which certificate to present?

7. draft-hzhwm-start-tls-for-dns-00, not specified for UDP

I am personally a fan of investigating ways in which opportunistically-persistent pools of TCP connections between DNS clients and servers could be used as an alternative to today's UDP spray, which as we know has a habit of bouncing off the urinal wall and making a mess of other peoples' shoes. I think we are some distance from understanding the operational implications of this, however, and it seems like a shame to gate this privacy proposal on that problem being solved. Pretty sure Duane called this out already, but I mention it again if for no other reason than to subject everybody to a toilet metaphor.

4. draft-wijngaards-dnsop-confidentialdns-00, let's use EDNS0

It solved some (not all) response size concerns for DNSSEC to have the DO bit specified in the EDNS0 header, since you then can't ask for a secure response without supporting EDNS0 and hence larger buffer sizes. Encrypted data (with padding) is also going to lead to larger responses; the same benefits might apply.

17. draft-wijngaards-dnsop-confidentialdns-00, architectural considerations

In the past when there was a desire to change the message format semantics, the OPT pseudo-RR was specified. If we consider this an established architectural approach, then we might consider that this proposal is also changing message format semantics; perhaps encryption of the various sections in the DNS message could be signalled through a similar pseudo-RR as an alternative to hiding encrypted data within a standard-format RRType (which seems a bit ugly). Perhaps it's worth re-casting this proposal as an EDNS0 option, or even as an EDNS1.

EDNS0 options are hop-by-hop. It's not obvious this is what we need, since that makes every intermediate DNS server a potential interception point. But perhaps that's ok anyway, if we imagine the 80% solution involves stub -> resolver -> authority where each arrow is a separate privacy domain anyway.

3b(ii). draft-wijngaards-dnsop-confidentialdns-00, ability to assert capabilities using DNSSEC

The ability of a zone manager to assert the capabilities of the authoritative servers for that zone, and sign that assertion with DNSSEC, seems like a strength of this proposal in the sense that a client can gain confidence in the availability of a secure channel to an authoritative server, and can plausibly reject responses that suggest that the server is not capable for fear that they have been injected by an intermediary.

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:12:35 +0000

On Tue, Mar 04, 2014 at 06:15:37PM +0000,
 Joe Abley <[email-masked]> wrote 
 a message of 34 lines which said:

> EDNS0 options are hop-by-hop. It's not obvious this is what we need,
> since that makes every intermediate DNS server a potential
> interception point. But perhaps that's ok anyway, if we imagine the
> 80% solution involves stub -> resolver -> authority where each arrow
> is a separate privacy domain anyway.

More generally, we need to decide whether we want a truly end-to-end
solution (which would be very much at odds with the architecture of
the DNS) or if we are happy to protect only the messages in transit,
leaving the issues of syping by intermediate servers to other
solutions (QNAME minimization, local caching resolvers...).

---

From: João Damas <[email-masked]>
Date: Wed, 5 Mar 2014 14:40:42 +0000

On 05 Mar 2014, at 14:12, Stephane Bortzmeyer <[email-masked]> wrote:

> solutions (QNAME minimization, local caching resolvers…).

perhaps there is a need to separate the problem into tractable chunks.
For the part of the problem about authenticating the recursive resolver (the fake 8.8.8.8 problem) we probably a different solution than for the metadata snooping problem (who is asking for what).
Perhaps it might be the case there are already existing features that can be used to get what we need (e.g. SIG(0) for the recursive resolver, wild!) and, as Roy Arends was mentioning over a few drinks, onion-like routing to separate the who from the what in questions in an effective manner.
These could be even user-triggered on demand for certain traffic types (For instance as a consequence of turning on private browsing in a browser), so the overhead penalties are only incurred for the desired subset of traffic.

Joao

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 5 Mar 2014 15:02:58 +0000

On 03/05/2014 02:40 PM, João Damas wrote:
> 
> perhaps there is a need to separate the problem into tractable
> chunks. For the part of the problem about authenticating the
> recursive resolver (the fake 8.8.8.8 problem) we probably a
> different solution than for the metadata snooping problem (who is
> asking for what). Perhaps it might be the case there are already
> existing features that can be used to get what we need (e.g. SIG(0)
> for the recursive resolver, wild!) and, as Roy Arends was
> mentioning over a few drinks, onion-like routing to separate the
> who from the what in questions in an effective manner. These could
> be even user-triggered on demand for certain traffic types (For
> instance as a consequence of turning on private browsing in a
> browser), so the overhead penalties are only incurred for the
> desired subset of traffic.
> 

+1. I don't want to fight about requirements for 10 years, and it does
look like there are different and competing views as to what
constitutes confidentiality here. So a split into several problems,
which can have shared or separate solutions, seems like a good start.

Jelte

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 05 Mar 2014 15:04:38 +0000

> which can have shared or separate solutions, seems like a good start.
The Chairs have no intention of letting any requirements vetting take 
the 'allotted IETF time' of 10 years.

If we split it into multiple problems, then so be it.