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

"Wellington, Brian" <bwelling@akamai.com> Wed, 21 April 2021 19:58 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 EC57C3A34D0; Wed, 21 Apr 2021 12:58:57 -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 PR8V9OSo15xs; Wed, 21 Apr 2021 12:58:53 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 55AA83A34CF; Wed, 21 Apr 2021 12:58:53 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 13LJnUJJ007030; Wed, 21 Apr 2021 20:58:51 +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=wWXAZ76IOjWx8t4Hy9KwN1gFUcipVTtLbK6RLzI1LiQ=; b=jvvxJo+RS87WfBdaRIWzQLmJ28FrxZ5TOtuaFO8MfjPZuJgZ1KCcp3M2XNJqG06Nu1Lc L8w2XVwn+yRcxtIFjJHz4VXAN4igljVmsVDiZZKqMnB6fiY/yQzPZ8SlZmVcyJ7Xpg0c zTx31zaRV2l0F8o1aP4RQHXC8a76za2rKgFINkP1i+Ni2L87GME7QpEkykn0Ehb7742i OXB0cEqn4nWcd9S+NMnGCkHEGve3WaNDHBoGXPyL4EzFDegi4q1YNYvx+6CKqH4Akh+7 tdcqX2bKTYkYyNUTg7XvWnolhojRPX4bnTeUvoF+x72qVsAeRlcZGYbApmJQP3PttOxe Mw==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 382700dhdm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 20:58:51 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 13LJnuDH007251; Wed, 21 Apr 2021 15:58:50 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 382gb4952j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 15:58:50 -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 Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Apr 2021 15:58:49 -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 15:58:49 -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/RosAgAAqIgCAAATAAIAABpuAgAAaVYCAAAWKgIAACQuAgAACLoA=
Date: Wed, 21 Apr 2021 19:58:49 +0000
Message-ID: <3B75734B-3F5E-4913-9BF5-B1C3A19BE0A2@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> <6245BB4F-4E2F-435F-ABC0-18C0420C8541@akamai.com> <CAHbrMsDGq0usDiqr0HtbFCR4Y8swtyv_0i7UOFf=C_ExW+0FNQ@mail.gmail.com> <303AD4A1-A9BE-4C31-B730-7B4D42587206@akamai.com> <CAHbrMsCj8OToEhjo7O0YkW4WGosGK7stBYTneYHUoX_KckY7Uw@mail.gmail.com>
In-Reply-To: <CAHbrMsCj8OToEhjo7O0YkW4WGosGK7stBYTneYHUoX_KckY7Uw@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.84.242]
Content-Type: multipart/alternative; boundary="_000_3B75734B3F5E49139BF5B1C3A19BE0A2akamaicom_"
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 suspectscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210136
X-Proofpoint-ORIG-GUID: Fs_19Kd6qgDyk0LHgO6fI3fw7pZqt6Je
X-Proofpoint-GUID: Fs_19Kd6qgDyk0LHgO6fI3fw7pZqt6Je
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 mlxlogscore=999 clxscore=1015 bulkscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210136
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=bwelling@akamai.com smtp.helo=prod-mail-ppoint1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/STWiPged-OPctc4y1u34qsOwPmE>
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 19:59:04 -0000

That looks good to me.

Brian

On Apr 21, 2021, at 12:51 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org<mailto:bemasc=40google.com@dmarc.ietf.org>> wrote:

Here's a proposed text change that I hope can satisfy both of our requirements: https://github.com/MikeBishop/dns-alt-svc/pull/319

The key sentence is:

To ensure compatibility with complex SvcParam specifications, recursive resolvers MAY validate the values of recognized SvcParamKeys, but MUST NOT reject the record on this basis unless a value is obviously invalid.



On Wed, Apr 21, 2021 at 3:18 PM Wellington, Brian <bwelling=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>> wrote:


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

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

But surely by this standard all fields are bytestrings?

They’re all sequences of bytes, sure.  But all of the defined parameters do have syntactic structure, and resolvers should be allowed to do the same level of syntactic checking for SVCB/HTTPS records as they do for records of other types.  If there’s checking which is clearly out of the scope of the document (like URL validation), that is fundamentally different than checks like “the IPv6 address is 16 bytes”.


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.

It sounds like you are suggesting that we distinguish between "how the resolver should parse the value" and "how the client should parse the value" ... but the value is meaningless to the resolver, so there is no particular sense in which the resolver should parse it.  This is not like JSON, where an intermediary might check that the value of the "url" key is a string, without checking whether it is a valid URL.  All SvcParamValues are opaque bytestrings unless you know how to parse them.

Again, there is a difference between syntax and semantics.  The resolver should be allowed to check that something conforms to the syntax specified in the spec, even if it doesn’t use the value.

Resolvers do not use the contents of most DNS record types, other than the ones which are used part of the DNS protocol itself (NS, A, AAAA, and the DNSSEC records).  That does not mean that it shouldn’t check the formats of other known records when possible.


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.

Similarly, there's no requirement here that resolvers be able to convey a syntactically invalid SvcParams structure (i.e. truncated TLV).  The requirement is that resolvers are, in general, able to convey records even if a SvcParamValue does not appear to be valid according to the key's specification.  This is particularly relevant for multipurpose codebases that can act as both recursive and authoritative (or client).  Such codebases must contain full SvcParam validation logic for all recognized SvcParamKeys, but they must be able to bypass it in recursive mode to avoid ossification.

This is absolutely not true.  Once the format of an rdata type (or a subtype, like an SVCB parameter) is defined, it must not change.  The authors of this spec surely know this, as there was a lot of discussion about the incompatibility of the echconfig->ech change, and how something like this could never happen in a standardized type.  A correctly implemented resolver should never reject a valid parameter as invalid, and if there is a need to change what the definition of a valid parameter is, that requires defining a new parameter type.

This is not a requirement that resolvers always pass through these invalid values, and in many cases (e.g. "port") the validation is sufficiently trivial that enforcing it poses minimal compatibility risk.  However, I think this is worth highlighting because, in my own implementation, it was easiest to enforce full validation for all recognized keys (present and future) during recursive resolution, and some extra effort was required to make sure that invalid values could pass through.

It’s a requirement that recursive resolvers introduce new behavior to allow the avoidance of format validation for SVCB records.  You’re free to implement that in your own code, but it’s an onerous requirement for other implementors.

Changing the text to:

Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys, and
MAY be able to convey SVCB records with malformed SvcParamValues.

would be fine with me, and I’d ignore the MAY part.

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?