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

Ben Schwartz <bemasc@google.com> Wed, 21 April 2021 19:51 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 163B83A3466 for <dnsop@ietfa.amsl.com>; Wed, 21 Apr 2021 12:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, 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 Yot8_CQ6qbQT for <dnsop@ietfa.amsl.com>; Wed, 21 Apr 2021 12:51:20 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 396473A346A for <dnsop@ietf.org>; Wed, 21 Apr 2021 12:51:20 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id g9so26505521wrx.0 for <dnsop@ietf.org>; Wed, 21 Apr 2021 12:51:20 -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=G62+BTKHtRiv+MlvIjwj79Y+0+161X06E63AL4JJseM=; b=sre6bq2Vh0EmeY7GVQkZz1vTsygbMC6cMDZA/KL0G69Ui/UpXtaqU54/J3xKcCx27z 9yDeMyKfgqK0iT+43rRn6NGqs2HiLY0K1UzMktjlp7Q5Z4ONqR8GG/4CBWiNTynyUlCa kFbCLxYw+NCQT6XwV8FJzT4txDqINE9Igcwd4ejFVRkCTPL+5jiGJEwDjyPmK6Y2RRdY QXOnxSeLVp7onNeUbmoFWlbe+MHMalY2S85Yarsmq00xtNXqes1ePs6/qoY1Tj7nQzEL gQSDbeEV3Y6WyNwszf5rf61VfTdLrt8gW5CIqBeqHBAuSF9tjroRV7mSLnXwf7Zwd55r kpqA==
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=G62+BTKHtRiv+MlvIjwj79Y+0+161X06E63AL4JJseM=; b=NLXzkYId0i4amO4y+uPsUQmtb/wpvXxIfNHMVLHIdZejis+YE0Ow0PycfrDOsBxP2r hFm1DOKxeFKHbrudYN/FWnnB73oS8LIaBBO/TKX99vRbA48HI26Z7tXB4UAeNtXAP+EP rTrOXtxvR+sLWC5yWBUjsr6pRZYNjrReHgq26IYEBB38h8itI0tZBr3sVXhpj1rWrJUE dGlrcpsqrti9e3UGgY4o9J03kwL+J2zDPuPupnaSn2TpGBxEeLZrVRa8EzpU1mevAZLV cOltF5MruYvwP9IWRbaFCJ08oE/5JNhYRrAok9URgw0SijRiTn35BSFI74oOOGmOhNUY ruaw==
X-Gm-Message-State: AOAM530gVJRaV8jRI88HtAw6hSCvuVHFrdJzE+er5HtAVDZ6FYkoZw5D eat3uDzLJJR6VZqqohIcpz+6yMyJSbVO+3XgHej69w==
X-Google-Smtp-Source: ABdhPJwwcMmAQcttUfN+rEVIsapCh0QSciQ4tDf4I2QS2Rl28Yo4iBsFM1nGaWmSNyLGtuMXELe2uxrawNxGA86xUso=
X-Received: by 2002:a5d:640e:: with SMTP id z14mr29039298wru.258.1619034673141; Wed, 21 Apr 2021 12:51:13 -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> <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>
In-Reply-To: <303AD4A1-A9BE-4C31-B730-7B4D42587206@akamai.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 21 Apr 2021 15:51:01 -0400
Message-ID: <CAHbrMsCj8OToEhjo7O0YkW4WGosGK7stBYTneYHUoX_KckY7Uw@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="0000000000009a209a05c080e2f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/i8Cs-7dzH_8rLcCkkf-Ls0CO9XU>
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:51:23 -0000

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> wrote:

>
>
> On Apr 21, 2021, at 11:58 AM, Ben Schwartz <
> bemasc=40google.com@dmarc.ietf.org> wrote:
>
> On Wed, Apr 21, 2021 at 1:24 PM Wellington, Brian <bwelling=
> 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> wrote:
>>
>> 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?
>>
>>
>>
>