Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https
Petr Špaček <pspacek@isc.org> Thu, 08 April 2021 07:54 UTC
Return-Path: <pspacek@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90573A3F06 for <dnsop@ietfa.amsl.com>; Thu, 8 Apr 2021 00:54:49 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=LW8g+mJR; dkim=pass (1024-bit key) header.d=isc.org header.b=IMOsV7Ow
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 KxkDnwOsi0ZE for <dnsop@ietfa.amsl.com>; Thu, 8 Apr 2021 00:54:44 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 B26363A3F02 for <dnsop@ietf.org>; Thu, 8 Apr 2021 00:54:44 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 98F7D3AB000 for <dnsop@ietf.org>; Thu, 8 Apr 2021 07:54:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1617868482; bh=8AXpIikEkDG5NptWx3b1a2NeD4fVdQ22YIRkaMEqNuQ=; h=To:References:From:Subject:Date:In-Reply-To; b=LW8g+mJRcwhBLQfarieefiFGh7DOshUK1/J58UaofwQr6N8ImKez4qOSts31jKFrU VR4Axo2y3pm7p6VvG0j3aGASkiwxGaVDPnMMNxKccnHjZOb5pTJHZ9R5YH45/CIZI3 FX3+D1oPmDibDpfLAPz/mlJjwWQW5Njl0eopsVvg=
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5EC88160042 for <dnsop@ietf.org>; Thu, 8 Apr 2021 07:54:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EBA2B160072 for <dnsop@ietf.org>; Thu, 8 Apr 2021 07:54:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org EBA2B160072
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1617868482; bh=Q7eitz2ZI1tioJSbBAq9gwJOXUor2gWJQgTfcCtJZK8=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=IMOsV7Owkl6oEMJAo6GMX4uVzTEgY3rHE8NHRXjWN1d/nRmjnPNvjC/JRp7SSGozL Tg2Dz17bo2tAN6KH0P41RdWMc/VnVeTSiO4aR5ae6qG2W6tC3vqGGZlUJFI8c3dWJn UKMhrB7nH8h1ZcfjCYRaguNJvVHdCR2ppF9aN9Fs=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C5C1kJ5BAMmT for <dnsop@ietf.org>; Thu, 8 Apr 2021 07:54:41 +0000 (UTC)
Received: from [192.168.0.116] (ip-86-49-243-175.net.upcbroadband.cz [86.49.243.175]) by zmx1.isc.org (Postfix) with ESMTPSA id 84EE1160042 for <dnsop@ietf.org>; Thu, 8 Apr 2021 07:54:41 +0000 (UTC)
To: dnsop@ietf.org
References: <CADyWQ+Hg=XcMjT5BOxeV0F25sAT5QSZOEcdMHZiH1s0sS=1KzQ@mail.gmail.com>
From: Petr Špaček <pspacek@isc.org>
Message-ID: <9af6a2c1-70af-0ea6-52a5-36ae13159fdd@isc.org>
Date: Thu, 08 Apr 2021 09:54:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CADyWQ+Hg=XcMjT5BOxeV0F25sAT5QSZOEcdMHZiH1s0sS=1KzQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EnlTvi2bM9syQBCTbxF1hBro55Y>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 07:54:50 -0000
On 18. 03. 21 21:53, Tim Wicinski wrote: > > This starts a Working Group Last Call for draft-ietf-dnsop-svcb-https > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ > <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/> > > The Current Intended Status of this document is: Proposed Standard > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please > speak out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: 2 > April 2021 I realize I'm already late, but I think this is worth raising with the WG: Version -04 contains this: 4.3. General requirements Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR as opaque and SHOULD NOT try to alter their behavior based on its contents. When responding to a query that includes the DNSSEC OK bit ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers MUST accompany each RRSet in the Additional section with the same DNSSEC-related records that they would send when providing that RRSet as an Answer (e.g. RRSIG, NSEC, NSEC3). The catch is that this "SHOULD NOT ... alter behavior" goes against RPZ and any other filtering technique employed by the resolver. As a specific example, operators are already asking resolver vendors to treat ipv4hint and ipv6hint the same way as A/AAAA for purposes of the "Response IP Address" Trigger in the context of RPZ filters. (https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3) Does WG want to say anything in the HTTPS draft or leave it to the imagination of vendors? In my eyes, 4.3 "SHOULD NOT ... alter behavior" is unnecessary for interoperability, so I think clarification is needed to make it clear that local policy on resolver overrides "SHOULD NOT alter" instruction in section 4.3. General requirements _if_ resolver operator deems necessary. Let me be clear: It would not be very reasonable to believe that HTTPS RR will be in practice allowed to work as a loophole to A/AAAA filtering on resolvers, so the question is if WG prefers to have it mentioned in the RFC text or not. -- Petr Špaček
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Pieter Lexis
- Re: [DNSOP] Working Group Last Call for draft-iet… Ben Schwartz
- Re: [DNSOP] Working Group Last Call for draft-iet… Petr Špaček
- Re: [DNSOP] Working Group Last Call for draft-iet… Ben Schwartz
- Re: [DNSOP] Working Group Last Call for draft-iet… Petr Špaček
- Re: [DNSOP] Working Group Last Call for draft-iet… Peter van Dijk