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

> -----Original Message-----
> From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Daniel
> Kahn Gillmor
> Sent: Saturday, May 23, 2015 12:12 AM
> To: Tim Wicinski; dns-privacy@ietf.org
> Subject: Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls
> 
> 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)

Agreed, will update the draft.

> 
> 
>  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.

Okay, will update that this section is non-normative. 

> 
> 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.

Yes, will keep it outside the scope and not soot it down.

Cheers,
-Tiru

> 
> Regards,
> 
>         --dkg
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy