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

Ben Schwartz <bemasc@google.com> Wed, 21 April 2021 17:01 UTC

Return-Path: <bemasc@google.com>
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 6D38E3A2FAA for <dnsop@ietfa.amsl.com>; Wed, 21 Apr 2021 10:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Xyc84E81cHp4 for <dnsop@ietfa.amsl.com>; Wed, 21 Apr 2021 10:01:11 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613763A2F8A for <dnsop@ietf.org>; Wed, 21 Apr 2021 10:01:11 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id d200-20020a1c1dd10000b02901384767d4a5so1672831wmd.3 for <dnsop@ietf.org>; Wed, 21 Apr 2021 10:01:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y1xOjMIcJyT+Lks2FbmLV26YgbuhiTt6pHRB7vzdG24=; b=sLxnNdfujkwHPBvL0NBx3V3iyBgTReZ4ueFlTBPQkH8WhMG6BWpcGCUfozX3at48oo MIFzgMTYKE7RrNg7JVCazQRf53e5LoemLhbFnX2gbDIUSdsP04ramhhftCxqpP86W+SP u+ZCp13PxIeGGmw5Yr9fq/x4ficyhJaPHNQ789CuNBWbjYYYdlK36NTluVM9H9+UtWa2 6N5YxSopnvdFzUce19OR8+fjsj8VciAti2nSjxbwyIqZwe9jNKHKrnCHBmaJoug/nCRc 4MEHv/eVqpRzox+k0WnLQth73HAg8/YDBgY0JGrOemT/h/MNMKKzbHXn80/o/NsBrLEF s4Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y1xOjMIcJyT+Lks2FbmLV26YgbuhiTt6pHRB7vzdG24=; b=tkMdfAqMzdnV82QCmdqoVzhc/Pe6JiNuS+fsPJhXTNadhoO9PeK7ONxO/7xQDYfvIR t+HbkCGtMmfcAKBKiXOuujg4x7Y5836E8AOSms5fhUhtLdbwH9tq4XFBds6S2xyVjxxU q8SQnL8+gaZhzLo1MYtmVJIuClOnUiea5DtpuZOKX46TlAvl22lx+UToCz7TzdB/8qM1 J5SjjQAVJvgbIeZJ8NbVTdYQDu3fb0P0ZVTGPd3AC9AKeu19bJWFExEN++XduVpvuoTd y3WmOvvDWe2K+IWhMFkRmVfADcztV4ygyXcKNHWMmoGOi3Znqp+66zuB5Rvnxj6EOTmk ESYg==
X-Gm-Message-State: AOAM530/8ajftksQD7tcv542XihORAPe7yNw/rPZWRPGxukQnXKTd18J dsw534bTkvdGZh+g++ThqHZDkflscbbXutG2alzzHQ==
X-Google-Smtp-Source: ABdhPJx3mXn6j8hnKwHw5kWilALq9TvPJOnvaeOH7Zbe9aDdoiycQgTIrcMCZZ24O5xqgQl5G3NsGFVF5IhDJbk62mI=
X-Received: by 2002:a1c:a182:: with SMTP id k124mr11000597wme.132.1619024467898; Wed, 21 Apr 2021 10:01:07 -0700 (PDT)
MIME-Version: 1.0
References: <161901308063.21005.875603362157576926@ietfa.amsl.com> <CAHbrMsA4TMfE+3LAT+un0FF3DGXKsYB1zAtvUwf2YKr97mJ+sQ@mail.gmail.com> <87B615B4-9CA3-4060-93C2-E4B953C11FB2@akamai.com>
In-Reply-To: <87B615B4-9CA3-4060-93C2-E4B953C11FB2@akamai.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 21 Apr 2021 13:00:56 -0400
Message-ID: <CAHbrMsDaqrQ+XDO4z395tC_yOH4MBH8OmoH8zTXWEHfcDC1+Ew@mail.gmail.com>
To: "Wellington, Brian" <bwelling=40akamai.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000527f7905c07e820d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rvSf7kZESJ7LA2QQH49Mi0ryZdY>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
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: Wed, 21 Apr 2021 17:01:19 -0000

On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian <bwelling=
40akamai.com@dmarc.ietf.org> 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?