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

[Mark Andrews <[e-mail]>]

> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]