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

Benjamin Kaduk <kaduk@mit.edu> Tue, 31 December 2019 06:25 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEE612002E; Mon, 30 Dec 2019 22:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrtiPF8in5lu; Mon, 30 Dec 2019 22:25:44 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3481200B3; Mon, 30 Dec 2019 22:25:43 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBV6PaRX006193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 01:25:39 -0500
Date: Mon, 30 Dec 2019 22:25:36 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mohit Sethi <mohit.m.sethi@ericsson.com>
Cc: gen-art@ietf.org, last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-bcp-op.all@ietf.org
Message-ID: <20191231062536.GS35479@kduck.mit.edu>
References: <157762745765.1150.7880025422884493076@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <157762745765.1150.7880025422884493076@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/YIFBBKyUc3QHodMZC7n-KwDujVs>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-dprive-bcp-op-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Dec 2019 06:25:45 -0000

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