Re: [dns-privacy] [Last-Call] Genart last call review of draft-ietf-dprive-bcp-op-07

[Benjamin Kaduk <[e-mail]>]

On Sun, Dec 29, 2019 at 05:50:57AM -0800, Mohit Sethi via Datatracker wrote:
> Reviewer: Mohit Sethi
> Review result: On the Right Track
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-dprive-bcp-op-07
> Reviewer: Mohit Sethi
> Review Date: 2019-12-29
> IETF LC End Date: 2020-01-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> This draft discusses privacy challenges for recursive DNS resolvers. It then
> describes policy and security considerations that DNS service providers can use
> for enhanced user privacy. The draft is 'On the Right Track' but not yet ready.
> 
> Major issues:
> 
> I wonder if section 5.1.2.1/5.1.3.1 should also talk about recommending OCSP
> stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you want
> to mention it here in section 5.1.2.1/5.1.3.1?
> 
> In section 5.1.2.1, what is meant by 'authentication domain names'? Later, the
> text says 'authentication name for the service'. I guess you are implying the
> authentic domain name of the DNS resolver service that the client software
> should verify through the common name (CN) in the certificate? Some more
> explanation here would be beneficial.

RFC 6125 has some useful terminology to talk about this sort of server-name
validation; for greenfield protocols the most common identifier type to use
is the DNS-ID, but the source of the name to be validated will still need
to be specified.

-Ben