> -----Original Message-----
> From: dns-privacy [mailto:[email protected]] On Behalf Of Daniel
> Kahn Gillmor
> Sent: Saturday, May 23, 2015 12:12 AM
> To: Tim Wicinski; [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
