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

"Wellington, Brian" <bwelling@akamai.com> Wed, 21 April 2021 17:24 UTC

Return-Path: <bwelling@akamai.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 9B0A03A3052; Wed, 21 Apr 2021 10:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 (2048-bit key) header.d=akamai.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 Cc6y2WZde4rM; Wed, 21 Apr 2021 10:24:39 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 B32EB3A304F; Wed, 21 Apr 2021 10:24:39 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 13LHFBCd002063; Wed, 21 Apr 2021 18:24:38 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=TUt/gZAT8ucOMO9VGHGZnWrnNq1YXqmVEfPOg+4JTYc=; b=Ro/j33Vl6iVNj12+2JXFylXMq3rswhskUtVakH7nM01LVxF2+mt7zetGET7NaPEN1Q7n j/DjE78f1HDT4uX4TmEdHn7zcdW7BcimlVA992o+21yhgYsXKwHo60yBt09PM6Gd43C+ kb/s14gyp/AMiT4KhWtMmiEw6VSCqbPX0QloikQcn5VwFSQwbsCZp5Q5ddWB5VvzZilH Y+8xl306TaYNDHaFGvkUql4hT4WypLz1EwjJbMIUmN1A//XArAhiYv4HV80qWBS5MW8Z 16/3Vkb8FbyPT3FUaImSBkJo75gqHu3DXcnuBu8EZu6VFbaDuNPWV7Bia7/jkas+IzF+ 6Q==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 3826ejmv05-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 18:24:37 +0100
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 13LHJG24030897; Wed, 21 Apr 2021 10:24:36 -0700
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 382mnfrdxd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 10:24:36 -0700
Received: from usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Apr 2021 13:24:36 -0400
Received: from usma1ex-dag3mb4.msg.corp.akamai.com ([172.27.123.56]) by usma1ex-dag3mb4.msg.corp.akamai.com ([172.27.123.56]) with mapi id 15.00.1497.012; Wed, 21 Apr 2021 13:24:36 -0400
From: "Wellington, Brian" <bwelling@akamai.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Thread-Index: AQHXNrV21gzSSzkj5Ua8FziWi6xrT6q/RosAgAAqIgCAAATAAIAABpuA
Date: Wed, 21 Apr 2021 17:24:36 +0000
Message-ID: <6245BB4F-4E2F-435F-ABC0-18C0420C8541@akamai.com>
References: <161901308063.21005.875603362157576926@ietfa.amsl.com> <CAHbrMsA4TMfE+3LAT+un0FF3DGXKsYB1zAtvUwf2YKr97mJ+sQ@mail.gmail.com> <87B615B4-9CA3-4060-93C2-E4B953C11FB2@akamai.com> <CAHbrMsDaqrQ+XDO4z395tC_yOH4MBH8OmoH8zTXWEHfcDC1+Ew@mail.gmail.com>
In-Reply-To: <CAHbrMsDaqrQ+XDO4z395tC_yOH4MBH8OmoH8zTXWEHfcDC1+Ew@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.94.169]
Content-Type: multipart/alternative; boundary="_000_6245BB4F4E2F435FABC018C0420C8541akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-21_05:2021-04-21, 2021-04-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210123
X-Proofpoint-ORIG-GUID: FX4_m8GjHnxd8q8SH_UYM_IpO0n_MEoJ
X-Proofpoint-GUID: FX4_m8GjHnxd8q8SH_UYM_IpO0n_MEoJ
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-21_05:2021-04-21, 2021-04-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 spamscore=0 bulkscore=0 impostorscore=0 phishscore=0 mlxlogscore=999 adultscore=0 clxscore=1015 mlxscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210123
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.60) smtp.mailfrom=bwelling@akamai.com smtp.helo=prod-mail-ppoint5
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/r09IKkRdRiBGCTdXxt-nmYs223c>
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:24:45 -0000

Yes, I think that sentence should be changed.  I’d suggest removing the "malformed SvcParamValues” part, but others may disagree.

I agree that a URL is a tricky case.  The spec writer might not want to include an ABNF representation of a valid URL, because implementors would likely want to use existing facilities to parse URLs, which are likely not consistent.  In that case, though, I would expect the spec to indicate that the field is a bytestring, and the resolver to be able to that.  The fact that it’s a URL is something that the client should be checking.

For the existing parameters, there are checks that can (and should) be made; that IPv4 addresses, IPv6 addresses, and ports are of appropriate length, that the ALPN field has the right length prefix, and that the mandatory field is ordered and has a valid length.

There are also checks which are not specified, and which a client may want to do, but are not part of the record format itself.  I wouldn’t expect a recursive resolver to reject a record containing an ipv4hint with the address 255.255.255.255, but that doesn’t mean that a client should try to connect to it.

I do not think that it should be required that a resolver is able to convey malformed records, where malformed is (only) referring to the syntactic content.  That’s not how resolvers work for other types; no resolvers have options to allow 5 byte A records.

Brian


On Apr 21, 2021, at 10:00 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org<mailto:bemasc=40google.com@dmarc.ietf.org>> wrote:

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