Re: nearing completion for HTTPS RR type (and SVCB RR type)

[Martin Thomson <[e-mail]>]

Hi Erik,

Thanks for passing this along.  I think that this is - as you say - almost done, but not perhaps in the same way that QUIC is almost done.  It's pretty good for a -00 draft, but I found a fairly large number of issues in my review.  Those were mostly editorial or quite minor, but it suggests that maybe another round of edits would be good.

I don't quite see the same decoupling from Alt-Svc that I was expecting based on your note.  I think that the balance there is about right, but I would frame this as a parallel mechanism to Alt-Svc that is deliberately compatible.

As for implementation, we have plans to implement as a client.  They are not concrete plans, however, so don't ask about dates.  I expect that more feedback will be forthcoming as that happens; if you believe that this can ship before then, then I would hope that you would be able to get some experience with client implementations in lieu of what we can provide.

I also think that the requirements for recursive resolvers are such that experience with implementation there is similarly necessary.

On Thu, Jun 18, 2020, at 12:48, Erik Nygren wrote:
> We're hoping to start WGLC in DNSOP sometime in the next month or two
> for the HTTPS RR type (formerly "HTTPSSVC", along with SVCB).
> We submitted an early code point allocation request for the DNS RR types.
> As such, now would be a good time to take another read through.
> 
> Remaining issues are tracked here (and can be discussed here,
> in dnsop, or in the issue tracker as appropriate):
> 
> https://github.com/MikeBishop/dns-alt-svc/issues
> 
> The most relevant to the HTTP WG are:
> 
> * Consider SVCB-Used header 
> <https://github.com/MikeBishop/dns-alt-svc/issues/107>
> * Parameter to indicate no HSTS-like behavior 
> <https://github.com/MikeBishop/dns-alt-svc/issues/100>
> * Consider a way to indicate some keys as "mandatory" 
> <https://github.com/MikeBishop/dns-alt-svc/issues/166> 
> 
> Note that the current draft decouples itself fully from Alt-Svc.
> That there are a few areas for future improvement to Alt-Svc
> that came out of discussion here, but are not covered in the current draft.
> 
> The latest authors' draft (for pull requests) is at:
> 
> https://github.com/MikeBishop/dns-alt-svc/blob/master/draft-ietf-dnsop-svcb-https.md
> 
> and latest published is at:
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00
> 
> Best, Erik
> 
> 
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Fri, Jun 12, 2020 at 4:18 PM
> Subject: New Version Notification for draft-ietf-dnsop-svcb-https-00.txt
> To: Benjamin Schwartz <[e-mail]>om>, Erik Nygren 
> <[e-mail] <mailto:[e-mail]>>, Mike Bishop 
> <[e-mail]>
> 
> 
> 
>  A new version of I-D, draft-ietf-dnsop-svcb-https-00.txt
>  has been successfully submitted by Ben Schwartz and posted to the
>  IETF repository.
> 
>  Name: draft-ietf-dnsop-svcb-https
>  Revision: 00
>  Title: Service binding and parameter specification via the DNS (DNS 
> SVCB and HTTPS RRs)
>  Document date: 2020-06-12
>  Group: dnsop
>  Pages: 39
>  URL: 
> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-svcb-https-00.txt
>  Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>  Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop- 
> <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>svcb-https-00 <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>
>  Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-s 
> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https>Consider a "mandatory" key range <https://github.com/MikeBishop/dns-alt-svc/issues/166>s <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>vcb-https <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https>
> 
> 
>  Abstract:
>  This document specifies the "SVCB" and "HTTPS" DNS resource record
>  (RR) types to facilitate the lookup of information needed to make
>  connections for origin resources, such as for HTTPS URLs. SVCB
>  records allow an origin to be served from multiple network locations,
>  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 proposal is inspired by and based on recent DNS
>  usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long
>  standing desires to have SRV or a functional equivalent implemented
>  for HTTP). These proposals each provide an important function but
>  are potentially incompatible with each other, such as when an origin
>  is load-balanced across multiple hosting providers (multi-CDN).
>  Furthermore, these each add potential cases for adding additional
>  record lookups in addition to AAAA/A lookups. This design attempts
>  to provide a unified framework that encompasses the key functionality
>  of these proposals, as well as providing some extensibility for
>  addressing similar future challenges.
> 
>  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.
> 
> 
> 
> 
>  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.
> 
>  The IETF Secretariat
> 
>