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

Ben Schwartz <> Thu, 20 May 2021 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EE553A27F0 for <>; Wed, 19 May 2021 18:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B-Js-nggtqnS for <>; Wed, 19 May 2021 18:35:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DC9A3A27EE for <>; Wed, 19 May 2021 18:35:19 -0700 (PDT)
Received: by with SMTP id v12so15860506wrq.6 for <>; Wed, 19 May 2021 18:35:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t4fWbmFC+WaPI4pN4lRzR+XT5/RNYSGG7P5sTAHvzkg=; b=dW+pBuqEte9p1WHsHkWOdUVynFenAs3eKkvzzJQyzdh6xvX24RnAPV5NMU7B8O8JMT K+7NMYbBNuKKozspAIpOqm8EUnJG9fsyl3/LQ231UFrNnWq78MEZD+cQcDssRfwcvNCF Q+ZiehSyWtsT7JRfso280BOL6VB+BtKVhPABy6127+LccOy52XkVYTVlvzdoJU4N/CRO mCxkeR6CdFyG9Txe+z6H4YYbEgYWfEuiZaN5QS0EbWL9kWYDBBFZ7QcDcb92ncMolIEH YLME9TkmhYHSwxNJ1YWrpgH4hFn6cjenBOFqeEPHz6EMv123e2tb7kpn0uFWopGjBHu7 5wdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t4fWbmFC+WaPI4pN4lRzR+XT5/RNYSGG7P5sTAHvzkg=; b=ZOdN+n9ejte/EsQZj7rs1xJnr7Y6erlDw8Tizzz8kDyIF5tRl78E8ub1rfijvxCALF uHPtDU5eh9CUjTwRZcLAFgSGr1Nj+OcYgHILB2tR1U7AIF0NgmKLWmIFUO6q9X5LcMPS 01FubeDsv7pGz78sjXb23vEv47phhHO8qL6SknnqShI4FJFqcb/NLWAStio1va9ZVcD4 zYx41DYfa4fNHMKowR7lAfdUwNK11VROyTyb6VUb2nsS44zp+hQ/iOS23oCBoiZAhoyk eMo9h4KHzPs5tSNeGxsUL3kJ4iev9aDouJZbsl60Cb9m46mc81ephLmvUOzd9rQPesTf rx0g==
X-Gm-Message-State: AOAM530TrxPKkvR5w/ul6G8Oo85c6M0s1MuTSL07A3BUDbma7A4LyiKD 8Lv4JC7TXPPmecOY2HLS8G3/1Yout5mBToOUAXuUZw==
X-Google-Smtp-Source: ABdhPJzqQfbhPrpythCswFD8KGFG3U2gOkazRpspVZBgQKYiRWUrjFTm7p3pVdpc8NvTqS1lfAQyMdg1y2udvSHa8II=
X-Received: by 2002:a05:6000:1145:: with SMTP id d5mr1647136wrx.404.1621474516374; Wed, 19 May 2021 18:35:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 19 May 2021 18:35:04 -0700
Message-ID: <>
To: Tommy Pauly <>
Cc: Erik Nygren <>, dnsop <>, John Levine <>, Brian Dickson <>, Eric Orth <>, Joe Abley <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000095c3a005c2b8f4e8"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 May 2021 01:35:26 -0000

On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <tpauly=> wrote:

> I like Erik’s suggestion that we solve the issues with parsing by putting
> more rules and constraints of the set of available characters, etc.

I don't get the impression that the TLS working group is likely to reach a
consensus to formally restrict the allowed characters in ALPN values.
However, there are currently no "problematic characters" in any of the
registered ALPN values, and it seems very likely to me that there never
will be.  With that gray area in mind, I have attempted to thread the
needle with the following proposed change:  The key sentence

> So long as there are no registered protocol identifiers containing "," or
"\\", zone file implementations MAY disallow these characters instead of
implementing the `value-list` escaping procedure.

I'm sure this is no one's favorite option, but perhaps it is good enough to
enable us to move forward.