[dns-privacy] Secdir early review of draft-ietf-dprive-unilateral-probing-07
Rich Salz via Datatracker <noreply@ietf.org> Fri, 09 June 2023 20:20 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5534AC151530; Fri, 9 Jun 2023 13:20:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rich Salz via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: dns-privacy@ietf.org, draft-ietf-dprive-unilateral-probing.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168634204133.61641.15990253589636399258@ietfa.amsl.com>
Reply-To: Rich Salz <rsalz@akamai.com>
Date: Fri, 09 Jun 2023 13:20:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/9_Erfvz7DcQxXEv5MaQM0NYAV9w>
Subject: [dns-privacy] Secdir early review of draft-ietf-dprive-unilateral-probing-07
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2023 20:20:41 -0000
Reviewer: Rich Salz Review result: Has Nits The term "unilateral" makes me do a double-take. That's probably on me, but I always think of it in a military context. So I am glad to see a short clear definition early in the document, in the terminology section. All of the comments below are optional. I am curious why Joey's affiliation is in the author's area but not the title page. Sec 2.1 I think before this there should be an intro sentence, like "There were two main priorities for this work" or some such. Also the "--" should probably be a colon. Sec 2.2 Is the main point of the first paragraph to say that DoQ and DoT don't address this type of deployment but leave it open for future docs? If so, maybe that's worth stating directly. Sec 3 I think the ALPN the client "should" use (lowercase) is better than "may use" Sec 3.1 Merge first two paragraphs Sec 3,2 A server *could* use a classic TLS server cert, right? Worth mentioning? Worth proposing an eKU for DNS? Sec 4.1 Is this 'happy eyeballs'? If so, worth mentioning I think. Sec 4.2, Merge the first two sentences: This document encourages the first strategy, to minimize timeouts or accidental delays and does not describe the other two." The remaining paragraphs contain some redundancy or otherwise could benefit from editing. For example, consider not saying anything about NS records. Sec 4.3, combine the two paragraphs that appear just after the table. Sec 4.4, combine first two paragraphs. Last paragraph seems out of place for this doc. Sec 4.5 In the table is "retain across reset" mean server restart? Are the last two paragraphs duplicate of 4.4? If not, I don't appreciate the difference; merge them into one. Sec 4.6, ah, happy eyeballs comparison. Consider a forward pointer from 4.1 Sec 4.6. Nice details. Does this borrow from what SMTP opportunistic does? If so, might be worth mentioning. Sec 4.6.3.1 "store early data" Is store the right word? Send or stuff comes to mind. Sec 4.6.3.3 Do not send SNI. Hmm. Okay. That's a big change from common web tls deployments. Worth calling out? Sec 4.6.8.2, can you point to specific sections in the RFCs? Okay if not. Sec 4.6.10, there's no title for the section referenced in 7858? :) Sec 5, "This document has no IANA considerations" is the boilerplate I've seen most often. Sec 6.2, A suggestion of what statistics to report would be useful. I also think the section title isn't great. Appendix A, is that to be removed when published? Should A and B explicitly say they are not normative?
- [dns-privacy] Secdir early review of draft-ietf-d… Rich Salz via Datatracker
- Re: [dns-privacy] Secdir early review of draft-ie… Tim Wicinski
- Re: [dns-privacy] Secdir early review of draft-ie… Salz, Rich
- Re: [dns-privacy] [Ext] Secdir early review of dr… Paul Hoffman
- Re: [dns-privacy] [Ext] Secdir early review of dr… Salz, Rich