Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Ben Schwartz <[e-mail]>]

On Wed, Sep 25, 2019 at 12:18 PM Jan Včelák <[e-mail]> wrote:

> On Tue, Sep 24, 2019 at 3:19 PM Erik Nygren wrote:
> > Following discussions around the "HTTPSSVC" record proposal in Montreal
> with the DNSOP, HTTP and TLS WGs, we've updated what was previously
> "draft-nygren-httpbis-httpssvc-03".  The new version is
> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
> feedback from the WG discussions, as well as feedback from discussions with
> the TLS WG (as we'd like to see this replace the need for a separate ESNI
> record).
>
> I support adoption of the draft by this working group.
>
> I generally like the content. I think the HTTPSSVC specifics leak into
> the generic SVCB specification a little but that could be polished
> later and I haven't noticed any outstanding issues.
>
> One thing I'm concerned about is the SvcParamKey wire format (and
> registry). You propose that each parameter would have a code point and
> a value encoded in a form specific to the parameter type. On one hand
> it will lead to compact encoding but on the other hand an introduction
> of new parameter type may become complex for the implementers. Have
> you considered encoding the parameters in a free form? Maybe as a
> string, similarly how SPF configuration is stored in the TXT record.
> It could look like this:
>
> example.com.      7200  IN HTTPSSVC 0 svc.example.net. ""
> svc.example.net.  7200  IN HTTPSSVC 2 svc3.example.net. "alpn=h3
> port=8003 esnikeys=\"ABC...\""
>

The original proposal used a text encoding similar to your description.  We
changed to a key-specific encoding due to complaints about the inefficiency
of base64-encoding ESNI keys.  I think the inefficiency of base64 encoding
is tolerable, but we adopted the feedback in favor of a binary encoding.

If the working group would prefer a textual wire format, that can certainly
be done.

The current draft attempts to minimize complexity for implementers by
offering a fully generic encoding for unknown key types.  For example,
"alpn=h3" can also be expressed as "key1=h3", and "port=8003" can also be
expressed as "key2=\031\067".  This encoding may not be convenient, but
hopefully it will reduce the burden of supporting new parameter types.

All of the value formats mentioned in the draft (raw, uint16, base64, IPv4,
IPv6) are already common in zone files.  If future parameters also stick to
popular formats, new parsing code should be minimal.


>
> Jan
>