Re: [dns-privacy] Erik Kline's Yes on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Thu, 06 May 2021 10:33 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874453A1C24; Thu, 6 May 2021 03:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
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 9CBobkQSBvXQ; Thu, 6 May 2021 03:33:39 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 B75493A1C22; Thu, 6 May 2021 03:33:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=oqKXQV2zvw3+vtxcQy2uM0KFHzE7cKIjrZgP50PFvpo=; b=mQrAaZVeSHHFVjsKN0Zpg6EhmY WNQOdeSV2K6BDl6RoSnoQF1Y76ZqQhGpE5/MhZ2QrskKjs1xJiF8Je+mpfwLK112RdcjIMA+HnI7J f1aYdZMpDFcHjhebhFgV06I2PMVF+E5Y9TwXu+0EUc4E4zhu8shhFFw0dz2LrH51ybm8qBwh5ugAV 0oKCcYmO0S+w9jssrsIGTEyRa47tNtGoxdbrfMpUf1PEmyik60BWPgCSy6clacmCSpWrrXr1mvVy/ SSw/gtZ0o2mySWdZ6Tds7jwThrmuadiJOOyPn4uMEY9UwVv/mTWU+S1XEAYQ+26iwttJQSPLHmVNT x+wbm7zw==;
Received: from [62.232.251.194] (port=15304 helo=[172.27.240.5]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1lebK5-0007Aj-1S; Thu, 06 May 2021 11:33:37 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <162018903197.29167.15668839813774854378@ietfa.amsl.com>
Date: Thu, 6 May 2021 11:33:35 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>, tjw.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <48B36952-1E45-4FCF-BBDD-D14EFE416243@sinodun.com>
References: <162018903197.29167.15668839813774854378@ietfa.amsl.com>
To: Erik Kline <ek.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.104.20)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/vQylltoGnTEsw6-xphVj3ncFBOQ>
Subject: Re: [dns-privacy] Erik Kline's Yes on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Thu, 06 May 2021 10:33:44 -0000


> On 5 May 2021, at 05:30, Erik Kline via Datatracker <noreply@ietf.org> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-dprive-xfr-over-tls-11: Yes
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ questions ]]
> 
> [ general ]
> 
> * The appendix discussion of ALPN made me think that some ALPN
>  recommendation might be worth mentioning.  The ALPN registry mentions
>  "dot" and claims RFC 7858 as the reference.
> 
>  However, I wasn't able to find a reference to "dot" in 7858 (certainly
>  not in the IANA section), nor in 8310 (which has only an empty IANA
>  section).
> 
>  Now I'm wondering where the "dot" ALPN really came from.  Nevertheless,
>  given this state of things, it best to continue to not say anything
>  specific about ALPN use on these XoT connections?
> 
>  (I'm fully prepared to accept "yes" as an answer, but support others'
>   ALPN concerns.)

Hi Erik, 

You’ll probably have seen the suggestion to Ben/Martin relating to adding the use of the ALPN? 

I agree that the reference to RFC7858 in the IANA section is incorrect. To the best of my knowledge that registration came as the result of a private request by Jon Reed in late 2019. And to my knowledge there is very little use of it in stub to recursive DoT today. 

Since those registrations are subject to Expert Review I’m not 100% sure of the precise way to get that entry updated but I would certainly like to see that happen. 

> 
> [[ comments ]]
> 
> [ sections 8.4 and 12 ]
> 
> * Section 8.4 has MUST for two of three client authorization strategies,
>  whereas section 12 has a lowercase "should" where these are listed for
>  inclusion in an XoT policy.
> 
>  "Should" there be more agreement in use of requirements language?

Thanks for catching this. I think the section 12 language pre-dates the current 8.4 requirements (early versions had SHOULDs there) so I agree: s/should/MUST/ in section 12. 

> 
> 
> [[ nits ]]
> 
> [ section 4 ]
> 
> * "The proposed mechanisms does not" -> "do not", or just "mechanism”?

just ‘mechanism’ 

> 
> [ section 6 ]
> 
> * "The term is used to encompasses" -> s/es//

Thanks!

Sara.