[dns-privacy] comments on draft-hallambaker-privatedns-01

[John Heidemann <[e-mail]>]

I took some time to read over draft-hallambaker-privatedns-01
carefully and take some notes.

I do not think this i-d is ready for WG adoption at this time.

My biggest concern is that the implementation complexity is unclear.
While I've heard comments about "the hard part of the problem is X and Y
is easy", but I'm having trouble assessing that in two ways.

First: how big is the spec?  While this i-d is short, it seems to depend
on [draft-hallambaker-wsconnect-08] which is another 34 pages of specs.
How do DNS implementers evaluate the effort in this aggregate?

Second, whatever protocol we pick must result in multiple independent
implementations.  It seems important to understand how many independent
implementations of there are today, and roughly how many lines of code
they entail.  While it doesn't belong in the i-d, it would be great to
hear more about this.

Detailed comments are below.

   -John Heidemann

----------------------------------------------------------------------

overall comments:

section 1:

"Private-DNS makes use of the JSON Service Connect (JCX) Protocol [I-
D.hallambaker-wsconnect] and the UYFM framing protocol described in that
specification.":  This reference seems to hide a fair bit of
complexity.  JCX may be "easy" (afterall, IETF already has 3 or 4
RPC-like protocols), but if I were a DNS software provider I read this
sentence and get concerned about implementation time.  Although not for
the i-d, one might wish to clarify the availability of libraries for
this protocol (ideally with different licensing), and the sizes of those
libraries (for people who will roll their own).

section 1.1:  "Like the Omnibroker protocol
[I-D.hallambaker-omnibroker], this proposal is built on JCX
[I-D.hallambaker-wsconnect]...":  I see [I-D.hallambaker-omnibroker] is
listed as normative.  Is that correct, or should it be informative?
(Again, I'm thinking about the minimum necessary implementation.)

section 2.1.1: "Following the use case [[U-PUBLIC] described in
[I-D.hallambaker- dnse], ...": DPRIVE seems to have settled on
draft-ietf-dprive-problem-statement-04 as a problem statement.  Does it
make sense to point at examples in that document?

"Since the example.com service does not require authentication...": why
is authentication not required here?  If Alice trusts her ISP, then
confidentiality is not required.  If she does not trust it, isn't
authentication necessary to prevent a person-in-the-middle attack?

section 2.1.2:  this section goes into challenge-repsonse.  Why is this
required since you already established a TLS session, thus presumably
proving identity and freshness?

setion 2: " The Query Protocol Binding wraps the [RFC1035] message structure 
rather than eliminating parts that are redundant. For example, the 
Query Protocol Binding Transaction ID which has a minimum length of 
128 bits supplements rather than replaces the DNS message transaction
ID...": should the i-d specific exactly which fields of the embedded
[RFC1035] query are to be replaced?

Overall, this section gives explicit examples about encodings,
but it doesn't actually specify the formatting.
For example, section 2.2.2.1 extracts keys
from the ticket, but ticket format is not specified in the i-d.

If these formatting details are external, I thinkthe section should clarify
that and give the reference.


section 2.2.3:  "A Private-DNS server MUST authenticate queries.".
Where is authentication specified?  


section 4. "Security Considerationsns" has placeholders for
confidentiality/integrity/access.  Since the goal of DPRIVE is to
improve security, it would be nice to fill in at least the
confidentiality subsection.

(The document could also be spellechecked.: s/Derrivation/Derivation/,
and s/Considerationsns/Considerations/.)