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

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: <internet-drafts@ietf.org>
Date: Fri, Jun 12, 2020 at 4:18 PM
Subject: New Version Notification for draft-ietf-dnsop-svcb-https-00.txt
To: Benjamin Schwartz <bemasc@google.com>, Erik Nygren <erik+ietf@nygren.org>,
Mike Bishop <mbishop@evequefou.be>



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