On Wed, Sep 25, 2019 at 7:17 PM Ben Schwartz wrote: >> 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.
This is a fair point. I don't have a strong opinion. > 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. I agree we need generic encoding. There is a way to express unknown record types (https://tools.ietf.org/html/rfc3597#section-5) and the syntax used there is more compact than what you propose. It uses hex strings instead of escaped decimal values. However its clumsy to work with records in that syntax and you proposal is better in that sense. I think this may become the most complex record type we have in DNS so far. None of the existing registered record types contain a list of key-value pairs of arbitrary length. Given that there is also a registry for key types involved it will be fun to implement the encoder/decoder. But we will have to deal with it. I'm interested in what others in this working group think. Thanks, Ben. Jan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
