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

[Willem Toorop <[e-mail]>]

No version of NSD, Unbound, ldns and getdns with SVCB and HTTPS support
has been released yet, so no problem for us to change the name of
SvcParamKey 5 to ech for us there, but ...

The Net::DNS perl library does have parsing and printing of SVCB and
HTTPS based on draft-ietf-dnsop-svcb-https-01 since version 1.26
(released on August 6, 2020). @Dick, what is your position on this?

I am aware of only 1 deployed HTTPS RR with echconfig:

crypto.cloudflare.com.	300	IN	HTTPS	1 . alpn=h2
ipv4hint=162.159.135.79,162.159.136.79
echconfig=AEf+CQBDABNjbG91ZGZsYXJlLWVzbmkuY29tACAjs5LfHm27uMBFmLDI++shXFnrIB3tDgU6gMZfkJoFYAAgAAQAAQABAAAAAA==
ipv6hint=2606:4700:7::a29f:874f,2606:4700:7::a29f:884f

Also, it would have been nice to have some test-vectors of RR's in
presentation format and wire format (in hexdump) in an appendix in the
document, to assist in the creation of interoperable implementations.
Maybe this can still be added?

-- Willem

Op 19-03-2021 om 09:05 schreef libor.peltan:
> FYI in Knot DNS, the implementation is at exactly the same state: an
> existing merge request. For us, it's technically no issue if the
> presentation/wire format changes during next few weeks.
> 
> I'm saying nothing about ideological consequences of such approach.
> 
> /Libor
> 
> Dne 19. 03. 21 v 0:05 Mark Andrews napsal(a):
>>
>>> On 19 Mar 2021, at 04:42, Tommy Pauly
>>> <tpauly=[e-mail]> wrote:
>>>
>>>
>>>
>>>> On Mar 17, 2021, at 6:04 PM, Ben Schwartz
>>>> <bemasc=[e-mail]> wrote:
>>>>
>>>> Release notes for this revision:
>>>>        *  Simplify the IANA instructions (pure First Come First Served)
>>>>        *  Recommend against publishing chains of >8 aliases
>>>>        *  Clarify requirements for using SVCB with a transport proxy
>>>>        *  Adjust guidance for Port Prefix Naming
>>>>        *  Minor editorial updates
>>>>
>>>> I'm only aware of one outstanding issue: a proposal to change the
>>>> name of the "echconfig" key to "ech".  This key corresponds to a
>>>> value that is an "ECHConfigList", which is a collection of
>>>> "ECHConfig" structs, and some implementers have reported that the
>>>> singular/plural name-value mismatch created confusion.  This issue
>>>> is discussed in detail here:
>>>> https://github.com/MikeBishop/dns-alt-svc/pull/299.
>>>>
>>>> This name has no effect on queries, responses, or zone transfers,
>>>> but it does appear in zone files.  Zone files will not be portable
>>>> between implementations that use different names.  This is true
>>>> whether we "burn" the current codepoint and allocate a new one, or
>>>> simply rename the current codepoint.  However, using a new codepoint
>>>> would allow updated implementations to support both names,
>>>> facilitating zone file portability in one direction.  It would also
>>>> be possible to support the old name with special-case name aliasing
>>>> logic.
>>>>
>>>> In my view, the temporary portability benefit is too small to
>>>> justify the permanent registry pollution of a deprecated codepoint,
>>>> especially because ECH itself is not yet finalized, and there are no
>>>> deployments except for standards development purposes.  However,
>>>> others have disagreed.  We'll need to reach consensus before making
>>>> any changes here.
>>> Personally, I’d prefer to see the name change, and not burn a
>>> codepoint, as long as we’re not breaking any zone files.
>>>
>>> I think the question is: does anyone have a zone that has actually
>>> deployed the echconfig parameter? I see many responses with
>>> SVCB/HTTPS records, but none with the echconfig in practice. If
>>> someone is aware of a production deployment that can’t move, please
>>> speak up!
>>>
>>> Tommy
>> It’s not so much is it in use or not.  As I said this is a process
>> issue.  When
>> the code point was assigned the way it was the wire and presentation
>> formats are
>> supposed to be *frozen* as that allows DNS developer to deploy code
>> without having
>> to worry about the specification changing underneath them.
>>
>> For BIND we haven’t shipped code with SVBC / HTTPS code points yet
>> even to the
>> point of parsing the records.  We have merge request that has been
>> tracking the
>> draft.  I never felt the specification was stable enough to do that
>> and unfortunately
>> I was correct.  ALPN has had its parsing changed, the same
>> presentation format produces
>> different wire formats.  echconfig vs ech is minor compared to that.
>>
>> I have not looked to see what other DNS vendors have done so far.
>>
>> If we go ahead there needs to be a section that specified the
>> differences in
>> parsing between the draft when the code point was issued and when the
>> RFC is
>> published.
>>
>> Mark
>>
>>>> --Ben
>>>>
>>>> On Wed, Mar 17, 2021 at 1:11 PM <[e-mail]> wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Domain Name System Operations WG of
>>>> the IETF.
>>>>
>>>>          Title           : Service binding and parameter
>>>> specification via the DNS (DNS SVCB and HTTPS RRs)
>>>>          Authors         : Ben Schwartz
>>>>                            Mike Bishop
>>>>                            Erik Nygren
>>>>          Filename        : draft-ietf-dnsop-svcb-https-04.txt
>>>>          Pages           : 48
>>>>          Date            : 2021-03-17
>>>>
>>>> Abstract:
>>>>     This document specifies the "SVCB" and "HTTPS" DNS resource record
>>>>     (RR) types to facilitate the lookup of information needed to make
>>>>     connections to network services, such as for HTTPS origins.  SVCB
>>>>     records allow a service to be provided from multiple alternative
>>>>     endpoints, each with associated parameters (such as transport
>>>>     protocol configuration and keys for encrypting the TLS
>>>> ClientHello).
>>>>     They also enable aliasing of apex domains, which is not possible
>>>> with
>>>>     CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
>>>>     origins.  By providing more information to the client before it
>>>>     attempts to establish a connection, these records offer potential
>>>>     benefits to both performance and privacy.
>>>>
>>>>     TO BE REMOVED: This document is being collaborated on in Github at:
>>>>     https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
>>>>     working version of the document, open issues, etc. should all be
>>>>     available there.  The authors (gratefully) accept pull requests.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>>
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop