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

Ben Schwartz <bemasc@google.com> Mon, 17 May 2021 22:48 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 9A21B3A113F for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 15:48:49 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dEt72nlo5mpQ for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 15:48:45 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 B363D3A113B for <dnsop@ietf.org>; Mon, 17 May 2021 15:48:44 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id i17so8018688wrq.11 for <dnsop@ietf.org>; Mon, 17 May 2021 15:48:44 -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=jy/5KdDJ7VMD94AY9MOMPikmtX/DNukkKD2ccwGfynU=; b=XYQT7PMYIVsgSfe9B/j9KZZV/S7XVvUs6wYuNxTYoKqtqADnObgGNfSDojCmBPdoaN kMPTupRRHaV8znM1XA+s01hiDL7nHF8upRXC1MZ/6V9RUsYYA9Bp2443IpNbHNGOk2SS k6hizJX4SwzxamgM6cWelTsO9QIp0N/nFzAjyLrDYBdwLYget77cPnwddwrP26w3DveP GP7SWYfszW02wvHbsAo9hrV+eD4CTniJ/4dmPwORNka7RD4FM/t76+59tzIbIr/dxw+G jd3JuSZoOWianPvuNmtAS0C+8+0jbrHHCGRcbu3CRSyZ4tlHk0/c2r9vcu4l5Heboc19 yacA==
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=jy/5KdDJ7VMD94AY9MOMPikmtX/DNukkKD2ccwGfynU=; b=m0/To8rF4Oefk8H55f99ctGkBRGPfSOFpF02h3XE25vmfdYVvCvJbR/fCU7fmyTbC4 R2W53JaEMTL3VKaMcZhzpgVNT6jHk1PF4jq56DCPf6zL5hICvQ2YItV68WeQFndz5+Uk Vzd5ZPkI11nsQuQtrBSVFOJ79vHGlPhacfRObiSvetkqMy550BHiw2EYjxeccT+Azqic NIcAOCA5q5W4TFf5K+CoTNwMF1U+2ezWGZWB2nDIlsHvRgEKOzn1U/vqoy/9xKs0CkPh t/HF2s93xQTb0mXlQaMoYDHjM/IbXHolZC5KxEahZQByxz52W68GC91GygM7Aj8HvCrw I06A==
X-Gm-Message-State: AOAM532gUSpQ2HqDwl/wmh1kZuOUzPs9ipAtCMz0F91s1QANSFL8qOpq eDnlerZvcSk3ap2wYtG/QdeqoKLbXaVRpWw7arpqb2N7sfy64rSG
X-Google-Smtp-Source: ABdhPJwEjXKMctyBupNnlrpKPn3kr9pcCTYILUcfRdE7Atyi/150LMw/h8gU6TMmrYHdPKCBKgPSz0g8lfpZtiMsQWY=
X-Received: by 2002:adf:f58e:: with SMTP id f14mr2478524wro.258.1621291722819; Mon, 17 May 2021 15:48:42 -0700 (PDT)
MIME-Version: 1.0
References: <7ADF1FB2-97A4-4C49-8F25-8BF03BE01640@hopcount.ca> <20210512213903.D5F1F7AA827@ary.qy> <CAMOjQcFJjcsvaREF0fr+2GTY4zTy5CxSxR16BEp=Nc-K9WJ0Tg@mail.gmail.com> <CAH1iCipAVKVCuH2ME=+YpeJyijrKCtzJaU3bRFyy1f48EB33iw@mail.gmail.com> <CAHbrMsCjWgV7nc575L_qdvr7HdoEVKqkXRwLdXA2L5NiCgdvwA@mail.gmail.com> <CAH1iCipW_-BSMQZ-S+m18pyzfxTGsCrmG9Pc-b35_VRiLhxh4w@mail.gmail.com> <CAHbrMsDvEkYAxee4xjW5LsQmr0PgBf+UmMAuME-_UvRMg4jJeA@mail.gmail.com> <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com> <CAH1iCioNgQMjEZSeRdD3OmxPsboybF4XfcdwEC-hEjBLGA88XA@mail.gmail.com>
In-Reply-To: <CAH1iCioNgQMjEZSeRdD3OmxPsboybF4XfcdwEC-hEjBLGA88XA@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 17 May 2021 15:48:31 -0700
Message-ID: <CAHbrMsAimEk-ubvAH8QsX=7amn5wm2a1sAyHhWox9nzOC2MofA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003d3dba05c28e6571"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fA3cT0F5_C-0Gx6Zp-e-5JJkK0Q>
Subject: Re: [DNSOP] [Ext] 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: Mon, 17 May 2021 22:48:50 -0000

On Mon, May 17, 2021 at 2:46 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

> I re-read (several times) the current -05 version of the draft. I found it
> difficult to follow and understand several aspects of the "automatically
> mandatory", "mandatory", and mandatory usage in the document, both
> syntactically and semantically.
>

I'm sorry this wasn't clear.  The text at the top of Section 7 defines the
terminology

   In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the
   RR will not function correctly for clients that ignore this
   SvcParamKey.  Each SVCB protocol mapping SHOULD specify a set of keys
   that are "automatically mandatory", i.e. mandatory if they are
   present in an RR.

...

> Here are some specific suggestions, including incorporating the updated
> proposed encodings:
>
>    - Use the term MTI (mandatory to implement)
>       - MTI parameters would be "alpn", (maybe) "no-default-alpn", and
>       (maybe) "port"
>       - The IANA table in 14.3.2 really needs an MTI column in addition
>       to the other columns
>
> In the HTTPS protocol mapping as presently defined, there are no MTI
parameters.  A compliant client implementation might not have any supported
parameters.  We could add a row for this in the table, but its value would
be "none".  (Future mappings may indeed have MTI parameters.)

As the table notes, the "automatically mandatory" parameters are
"no-default-alpn" and "port".  A client that doesn't support any parameters
would ignore any record that contains these parameters.

>
>    - For each binding registry,
>
> Mapping documents are IETF-controlled, not IANA-controlled, so there isn't
a "registry" per se.

an additional table column specific to that registry should be
> included/added: "non-negotiable", i.e. MTI for this binding.


A "service binding" is a single SVCB RR; I presume you mean the "mapping",
a document that defines how to use SVCB in some context.

It sounds like "non-negotiable" is a synonym for "automatically
mandatory".  I'm certainly open to changing the draft's terminology.
"non-negotiable" might be clearer, although I'm not sure what negotiation
it's describing.

>
>    - Replace the "mandatory" thing, with an "optional" flag to be
>    optionally appended to any parameters that are not "non-negotiable".
>       - This also removes the need to have a sorted list of mandatory
>       attributes
>       - Each binding will have a list of non-negotiable attributes, which
>       can be used for validating the "optional" flag on both the authority side
>       and the client.
>       - Any parameter that is not non-negotiable, but does not have the
>       optional flag, must be supported by the client for the parent HTTPS/SVCB
>       record to be accepted by the client.
>
> It sounds like this "optional" flag is exactly the inverse of the present
"mandatory" indication.  The present structure was chosen in part to
simplify the zone file and wire formats, by avoiding an additional mark
that must be written or parsed on every SvcParam.  Additionally, for
compatibility, it seems likely that the great majority of parameters will
either be automatically mandatory (as specified in the mapping document) or
optional (especially if they are introduced later), so making parameters
mandatory unless marked otherwise seems like the wrong default.

>
>    - The binding tables then become lists of parameter sub-types that the
>    specific binding uses, marked as optional-allowed or non-negotiable. The
>    binding table incorporates all the MTI sub-types as well.
>
> I'm not sure what you're describing, but note that new parameters can be
defined over time, and we do not want every new parameter draft to Update
the SVCB RFC.  The proposed parameter registration policy is
first-come-first-served, with the understanding that clients will normally
ignore new parameters that they do not recognize.

>
>    - The binding tables obviously still need default values (if
>    appropriate), e.g. for ALPN.
>
> The HTTPS binding would then consist of:
>
>    - Default ALPN of "http/1.1"
>    - MTI of "alpn"
>
> Note that declaring alpn to be "MTI" would have no effect.  As presently
defined for HTTPS, the "alpn" SvcParamKey only adds advertised protocols.
If you prefer to stick to the default protocol (TLS over TCP), you can
"implement" the alpn parameter by ignoring it.

>
>    - aNN of "port"
>    - NN of "no-default-alpn"
>    - Optional of "ecn"
>    - Optional of "ip4hint"
>    - Optional of "ip6hint"
>
> And an HTTPS referenced record (included by reference from record with
> SvcPriority between 1 and 127), would have the following rules:
>
>    - Any "optional" parameter MUST be implemented by the client, UNLESS
>    the "optional" flag is present in the HTTPS referenced record
>
> It seems you are drawing distinctions between "mandatory to implement",
"non-negotiable", "optional", and "flagged optional".  I don't believe this
is a simpler formulation than the current draft.  By working through an
alternative formulation, I think you've shown that the complexity is
irreducible.

I continue to prefer the current draft, as it provides the correct behavior
in ordinary cases with simple inputs like

1 . alpn="h2,h3" ech=...

>