Re: [DNSOP] SVCB ALPN value presentation format

Larry Campbell <> Sat, 13 June 2020 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B07A43A1029; Sat, 13 Jun 2020 12:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 y-yFwYt90ZUr; Sat, 13 Jun 2020 12:02:01 -0700 (PDT)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A06083A1028; Sat, 13 Jun 2020 12:01:55 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 05DIwrmx027029; Sat, 13 Jun 2020 20:01:55 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=jan2016.eng; bh=DanQMSdackr3QMbo8xL7xTDt9oaPuEHO9Prq9PF5ujU=; b=QhHFHlSN0GMTmPXoU387EoZoRP4BMt9M7koLzbQMe0rGX33517FCLZeqZq/GNnZiJ9+s +l5U618d+Fpw01d7P5q9U8LYIb/ELe87036H3jBRSUgsX1ENGO1GEg2HdtLEgq9wLAjY uU63JrV8iRHS6oMsc3gM9qZsz501aIppZA35M41IIvOM/lxnvXI94LeEMgBlgsSNrCu6 ibCH6+t0E0Jcjwtj1a43qicpCgH6vJJsUGCeGYOqIuR0nRxs3Aa9w5hO9GBY/n3G7r8B QmtS3tZP5PfjaQ40s1yePBTnX9FolDWEpErGvAs+pb3J2gOGi2lCLRVdalizr0fTZ+eV 6A==
Received: from prod-mail-ppoint6 ( [] (may be forged)) by with ESMTP id 31mp2rpm80-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 13 Jun 2020 20:01:55 +0100
Received: from pps.filterd ( []) by ( with SMTP id 05DIoQBH023213; Sat, 13 Jun 2020 15:01:53 -0400
Received: from ([]) by with ESMTP id 31mt4x9kbh-1; Sat, 13 Jun 2020 15:01:53 -0400
Received: from [] ( []) by (Postfix) with ESMTP id 7362921FB7; Sat, 13 Jun 2020 19:01:53 +0000 (GMT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Larry Campbell <>
In-Reply-To: <>
Date: Sat, 13 Jun 2020 15:01:53 -0400
Cc: dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Ben Schwartz <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-13_10:2020-06-12, 2020-06-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 spamscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006130168
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-13_10:2020-06-12, 2020-06-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 impostorscore=0 bulkscore=0 cotscore=-2147483648 suspectscore=0 clxscore=1011 lowpriorityscore=0 spamscore=0 adultscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006130170
Archived-At: <>
Subject: Re: [DNSOP] SVCB ALPN value presentation format
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: Sat, 13 Jun 2020 19:02:03 -0000

I think there's an implementation difficulty. Consider:

1.  alpn=h2		; clear enough
2.  alpn="h2"		; should be equivalent
3.  alpn=\h\2		; should also be equivalent
4.  alpn=h2,h3		; ok (two values)
5.  alpn="h2","h3"	; should be equivalent
6.  alpn="h2,h3"	; malformed? or a single alpn value of h2,h3? or two three-character values, "h2 and h3"?
7.  alpn=h2\,h3,h4	; how should this be parsed?

Section 2.1.1 tempts one to build the obvious implementation of using one's existing character-string parser, and then passing the parsed character-string to the individual handler for each key type. The alpn and ipv*hint handlers are going to want to split that character-string on comma. That would treat #6 as two two-character values (h2,h3). But #7 is problematic: the generic character-string parser would remove the backslash, and then the alpn handler would treat this as three alpn values when you probably wanted just two.

We could make a special character-string parser for alpn and ipv*hint, that handles commas, but it feels odd to have to use a special parser just for certain key types. However, if we must allow commas in alpn names, then we have no choice.

Perhaps it would be clearer to simply remove the three paragraphs of section 2.1.1 beginning with "The presentation for for SvcFieldValue is..." and ending with "...not limited to 255 characters.)". Since the previous paragraph says "Values are in a format specific to the SvcParamKey", perhaps it would be best to leave the description of each value format in the appropriate part of section 6 and for section 2.1.1 to discuss only how to represent and parse unrecognized keys.

To keep the implementation simple, the alpn value could be defined as a comma-separated list of sequences of printing ASCII characters, with embedded comma represented as \, backslash as \\, and all nonprinting and non-ASCII characters reprsented as \nnn. (In other words, the full generality of character-string, particularly double-quotes, is not needed here.

The other comma-separated value types -- ipv4hint and ipv6hint -- do not have this difficulty; they also don't need the full generality of character-string handling, because the individual values can contain only hex digits, periods, and colons, so their specification and implementation can be much simpler.

And I think section 2.1.1 would be clearer if

    using decimal escape codes (e.g. \255) when necessary

were replaced by

    using decimal escape codes (e.g. \255) for all nonprinting and non-ASCII characters, and using \\ to represent backslash

- lc

> On Jun 13, 2020, at 11:25, Ben Schwartz <> wrote:
> Larry,
> I think that's the intent of the current text, especially the ABNF for "element".  If you think it's unclear, we should adjust it.  Please suggest text!
> --Ben Schwartz
> On Sat, Jun 13, 2020, 10:53 AM Larry Campbell <> wrote:
> Seciont 6.1 says:
> > The presentation value of "alpn" is a comma-separated list of one or more "alpn-id"s. Any commas present in the protocol-id are escaped by a backslash:
> > 
> >     escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF
> >     escaped-id = 1*(escaped-octet)
> >     alpn-value = escaped-id *("," escaped-id)
> If I read this correctly, the presentation value is allowed to contain nulls and control characters. This seems likely to make such records very difficult to edit. Wouldn't it be better to require these to be encoded as \nnn?
> - lc
> _______________________________________________
> DNSOP mailing list