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

[Tommy Pauly <[e-mail]>]

I wanted to chime in on this discussion as a client-side implementor who has already widely deployed support for SVCB/HTTPS.

The current format, where the parameters are structured as a list within a single RR, is certainly simpler and less error prone for processing. Much of the information contained as parameters within the SVCB RR are useful for higher-level “application” logic. Within our deployment, the DNS stub resolver daemon receives the RR and does the parsing, and passes up the parameters bundle as a blob that is more or less opaque, to the layer that handles actual connection processing (doing happy eyeballs, protocol selection).

Processing the content of SVCB parameters must be handled atomically: the ALPN, ECH config, and any other information must be handled clearly as a unit and not have any chance of being broken up. Lots of code is already based on processing RRs as chunks of data, and requiring anyone looking at the information to stitch the parameter list back together based on multiple RRs that must be in a particular order adds complexity and invites in bugs and errors.

I’d strongly encourage sticking with the wire image we’ve already been using and deploying. 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. 

Best,
Tommy

> On May 17, 2021, at 2:58 PM, Erik Nygren <[e-mail]> wrote:
> 
> 
> On Mon, May 17, 2021 at 5:36 PM Ben Schwartz <bemasc=[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <[e-mail] <mailto:[e-mail]>> wrote:
> ... 
> Breaking the binding into pieces creates many new opportunities for error, such as having multiple TargetNames in a single binding.  It corresponds to a multimap datastructure instead of a standard map.  Every attribute of each binding would naturally be an unordered collection, which is a bad fit for attributes that are required to be singular, or an ordered list, or anything other than a set.
> ... 
> So, taking your observations about TargetName into account, and borrowing from the overloading of Priority to signal AliasMode, here's an alternative that I think addresses most of the concerns.
> Priority {AliasTarget | ServiceTarget | KeyName} {ServiceBindingPriorityValue | Value}
> where
> Priority == 0 => AliasMode
> Priority >0, <128 => ServiceMode
> Priority > 128 => ServiceBinding key-value record 
> 
> The same example would be encoded (again with only RDATA values):
> 1 target "h3pool" 128
> 128 alpn "h2,h3"
> 128 ech "123..."
> 2 target "." 129
> 129 alpn "h2"
> 129 ech "abc..." 
> 
> I find this format, with multiple lines and multiple integers per binding, much more difficult to read or write than the current draft, especially since the elements of each binding can potentially be spread across a zone file (perhaps by accident) in arbitrary order.
> 
> 
> I concur with Ben here.  Thank you for spelling out and proposing this alternative, but this seems much less usable
> and understandable by a typical user, either for zone publication or for reading diagnostic output from tools 
> like "dig" or for talking about in other drafts specifying SVCB.  
> 
> Side-note: some precursors to SVCB and earlier discussions in the working group
> proposed using a standardized format such as CBOR for encoding the SvcParams but
> that approach was discarded as bringing in a bunch of its own baggage and being too
> different from typical DNS usage.
> 
> An approach HTTP took was to define "Structured Field Values for HTTP" (rfc8941)
> which may be more complexity than is needed here, but perhaps there
> is a similar approach that could work for SVCB of defining explicit types
> for SvcParamValues?
> 
> Another approach could be seeing if there was a way to require
> everything to use a limited character set and require escaping
> for things outside of these constraints.  For example, alpn values
> with a limited set of token characters would be allowed as strings,
> but anything else would need escaping.  Would require base64 encoding
> of SvcParamValues wanting characters outside of "non-special" 
> be easier to parse, perhaps with a prefix to indicate that a string is base64 type?
> Are there other similar things that would keep the format similar to the existing
> format but reduce the number of parser special-cases needed?
> 
>      Erik
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop