Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2015-05-20 10:03:27 -0400, Tim Wicinski wrote:
> During the previous Call for Adoption a number of participants expressed 
> interest in adopting this work.  WG members felt it needed some 
> improvements, but thought it had potential. The authors addressed the 
> issues and feel it meets what the working group was seeking, and have 
> requested that we initiate a call for adoption.
>
> If the working group adopts this document, it only means it wishes to 
> study this solution more carefully.  The working group may still 
> determine to not move forward with it.
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-wing-dprive-dnsodtls/

I support the WG adopting this document for consideration.

I'm willing to review.

Looking at -01 of the draft:

 Section 3.2:

   Verifying the server certificate based on fingerprint needs to be
   spelled out more clearly (what exactly is fingerprinted, how it is
   fingerprinted).  But i don't think we should be fingerprinting the
   certificate itself at all in this case.  I think we should be
   fingerprinting the subject's public key.  The folks working on HTTP
   Public Key Pinning (HPKP) already went through this discussion, and
   settled on pinning public keys instead of certificates for good
   reason: in the pinning case, we want to make sure that we're looking
   at the same public key, not about the identity material wrapped
   around it in the cert.  (this also allows them to work with
   oob-pubkeys, as you recommend in section 7)


 Section 3.3:

   This section seems to bundle assumptions about DHCP information and
   system configuration all together ("an implementation will
   attempt"). I think we should separate those considerations, and make
   it clearer that this section is not a normative set of guidelines,
   but rather a description of common behaviors and choices.

Section 7:

   "amoritized" should be "amortized".  I'm not convinced by the NOT
   RECOMMENDED in this section. Especially as the root zone expands, it
   doesn't look all that much different than any other busy
   authoritative nameserver.  This sort of SHOULD NOT ought to be backed
   up by hard data, or some sort of operational characteristics (X
   number of clients, each querying Y times per day, or something), or
   else it looks like it would apply to all authoritative nameservers.
   I understand that we want dprive to focus first on the stub->resolver
   link, but i don't think we should shoot down using DNSSoD on
   resolver->authoritative links without more consideration.

Regards,

        --dkg