Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Petr Špaček <> Wed, 21 April 2021 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6D223A2FDF for <>; Wed, 21 Apr 2021 10:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=AT9XwWWE; dkim=pass (1024-bit key) header.b=bgShlRdZ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PdMmazaJntTT for <>; Wed, 21 Apr 2021 10:12:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DFB33A2A3E for <>; Wed, 21 Apr 2021 10:12:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 09D9E3AB01E for <>; Wed, 21 Apr 2021 17:12:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1619025163; bh=PWb0Nr3RJ8Q8GuZsVtQwGcNpT34b7/NNIV3socgZOfY=; h=To:References:From:Subject:Date:In-Reply-To; b=AT9XwWWE3HgLR/RwPVpOOrbcP6ZhSHs2LbgX0rZa3LScZeDZQ6rajm14TdpYpy9KB MpX3akFOlkXLZ42H0JXX1N5cGy1LUcCrlaVeUEci1SMsF8waq7lqYpSqW4dZ/n9JET ohnEiwm64GFVJrQg2S2B4Zc+cSWWpj6pXEcQJu4A=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id CFF75160075 for <>; Wed, 21 Apr 2021 17:12:42 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 6484E16006A for <>; Wed, 21 Apr 2021 17:12:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 6484E16006A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1619025162; bh=uWy6jWL57Cj/6Pnq9d0AVUTm67Jwj5ZAVA+5wbmiP54=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=bgShlRdZIVtMDPpRxcP0gCaohuQ4s51luEDfJE+T3wweAIBuV4LUBfy7rTM8UCYCZ ouIwDdtbmeBejyLxoL7oVFOuvi5k6QgDtxjGeiN3Pgp93ri6zSA12e/0Mdc785EdkY R+e7t9ucQB0da3iNNYDbX1dxEaRiAX854yHcD2Z8=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id 3rMS39LyPvel for <>; Wed, 21 Apr 2021 17:12:42 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id C31E4160046 for <>; Wed, 21 Apr 2021 17:12:41 +0000 (UTC)
References: <> <> <> <>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Message-ID: <>
Date: Wed, 21 Apr 2021 19:12:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2021 17:12:49 -0000

On 21. 04. 21 19:00, Ben Schwartz wrote:
> On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian 
> < 
> <>> wrote:
>     I’m not a fan of the new text in section 4.3:
>         Recursive resolvers MUST be able to convey SVCB records
>         with unrecognized SvcParamKeys or malformed SvcParamValues.
>     It is perfectly reasonable for a recursive resolver to reject any
>     malformed DNS record.  There’s a significant difference between
>     “malformed” and “unknown”.  A recursive resolver should definitely
>     allow records with unknown SvcParamKeys, but if the format of a
>     record is known, a resolver should be allowed (encouraged, in fact)
>     to check that it conforms to that format.
> The concern here was about differing interpretations of future 
> standards.  For example, if some SvcParamValue is defined as a URL (for 
> some future key), implementations are likely to disagree about whether 
> certain bytestrings are valid URLs.  (There are several definitions and 
> a zillion edge cases.)  The resolver has no use for these values, so the 
> most compatible behavior is to treat them as opaque bytestrings.
> We very deliberately chose the phrase "MUST be able to convey" to 
> recognize that resolvers might be configured not to convey a record with 
> a malformed value, but it should be possible.
> Do you think we should change this sentence?

I can see the same ambiguity as Brian.

What about this text as replacement?
Recursive resolvers MUST be able to convey SVCB records with 
unrecognized SvcParamKeys if they conform to RDATA wire format (section 

What I mean: Resolvers must be able to handle _unknown_ SvcParams as 
opaque byte strings.

Various resolvers will do some sort of filtering on individual params, 
but such filtering is "local policy" and nothing we write into the RFC 
can change local policy anyway. For that reason I would not go to great 
lengths to explain what to do with unrecognized URLs etc.

Petr Špaček