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

From: Erik Nygren <[email-masked]>
Date: Wed, 17 Jun 2020 22:48:52 -0400

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: <[email-masked]>
Date: Fri, Jun 12, 2020 at 4:18 PM
Subject: New Version Notification for draft-ietf-dnsop-svcb-https-00.txt
To: Benjamin Schwartz <[email-masked]>, Erik Nygren <[email-masked]>,
Mike Bishop <[email-masked]>

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jun 2020 15:44:33 +1000

Hi Erik,

Thanks for that. Reading through the document for the first time in a while, a few questions pop to mind:

* For those who haven't been following, can you explain why it was thought best to decouple form Alt-Svc?

* The introduction talks about SVCB 'provid[ing] clients with complete instructions for access to an origin.' 'origin' is a Web-specific term; is there a more neutral term you can use to distinguish it from HTTPS? I see in Terminology that you justify this for alignment with Alt-Svc, but that seems to assume that other protocols will have an origin concept -- in particular, a scheme (I'm not against aligning all potential protocols to this model, just a bit surprised that it's got this far).

* That brings to mind the SRV framework; is there any attempt to relate the SVCB framework to it -- especially since this appears to embed the ALPN view of the world? I'm sure some will want to know...

* Did you consider publishing these as two separate documents? That might make the layering more clear.

* Do we have statements of support for the delegation use cases from client implementers? This was a key purpose for Alt-Svc, but it wasn't implemented by clients widely.

* Section 7.5 gives the HTTPS record effective HSTS semantics. Has there been engagement with / review from the security community on this? In particular:
  * Are the presumably shorter DNS TTLs suitable for HSTS use cases?
  * Are there any other fixes / enhancements to HSTS that we want to layer in?

Cheers,

> On 18 Jun 2020, at 12:48 pm, Erik Nygren <[email-masked]> wrote:
> 
> To: Benjamin Schwartz <[email-masked]>, Erik Nygren <[email-masked]>, Mike Bishop <[email-masked]>
> 
> 
> 
> Title:          Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
> 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-svcb-https-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sConsider a "mandatory" key rangesvcb-https
> 
> 
> Abstract:

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 23 Jun 2020 19:25:32 +1000

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:
> To: Benjamin Schwartz <[email-masked]>, Erik Nygren 
> <[email-masked] <mailto:[email-masked]>>, Mike Bishop 
> <[email-masked]>
> 
> 
> 
> <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>
> <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:

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jun 2020 07:29:26 -0700

Thanks for filing issues on the GitHub, Martin!

Regarding the done-ness and implementations, I agree that this certainly isn’t as mature as QUIC. The key thing at this time is getting the wire format stable enough to do the RR type early allocation, which will enable broader interop and deployment testing. Seeing implementations ship prior to publishing the RFC here is an important step, as you indicate.

Tommy

> On Jun 23, 2020, at 2:25 AM, Martin Thomson <[email-masked]> wrote:
> 
> Hi Erik,
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 24 Jun 2020 09:07:44 +1000

On Wed, Jun 24, 2020, at 00:29, Tommy Pauly wrote:
> Regarding the done-ness and implementations, I agree that this 
> certainly isn’t as mature as QUIC. The key thing at this time is 
> getting the wire format stable enough to do the RR type early 
> allocation, 

I think that it is time to start this part.  Unless others agree with me regarding the size of the priority field, that is.

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jun 2020 16:40:37 -0700

Yes, there have already been lots of tests with the private BIND values! I’ve built and tested an implementation using that.

I think we’re ready at this point to do tests that are more than experiments, but larger deployment tests that are using the stable types.

Thanks,
Tommy

> On Jun 23, 2020, at 4:38 PM, Mark Andrews <[email-masked]> wrote:
> 
> One doesn’t need an early allocation for interop testing.  Just pick 2 private type values.  BIND uses SVBC/65481 and HTTPS/65482 which matches what dnspython is doing for their testing.  If the record format changes pick 2 new private values and discard the old ones.  Use “TBA (use 65XXXX for pre allocation testing)” in the draft so everyone is in sync with a particular WIRE FORMAT.  The final allocation can be made by IANA when the document is with the RFC editor.
> 
> I’ve done this a number of times with multiple RR types.
> 
>> On 24 Jun 2020, at 00:29, Tommy Pauly <[email-masked]> wrote:
>> 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [email-masked]
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jun 2020 00:51:55 +0100

On 24/06/2020 00:40, Tommy Pauly wrote:
> I think we’re ready at this point to do tests that are more than
> experiments, but larger deployment tests that are using the stable
> types.
+1

S.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 24 Jun 2020 22:20:35 -0400

> best to decouple form Alt-Svc?

Analyzing the interaction between Encrypted ClientHello (ECH), SVCB, and
Alt-Svc became extremely complex, and the resulting behaviors seemed likely
to be brittle.  One key point is that Alt-Svc was designed to be optional
(fallback to direct connection is always allowed), but this is not true for
any medium that can transfer ECH public keys ("ECHConfigs"), due to the
need for downgrade-attack resistance.  Retrofitting a no-fallback mode onto
Alt-Svc raised concerns about ECH key rotation (Alt-Svc cache lifetimes are
very long), ALPN negotiation, and CDN transitions/multi-CDN.

You can see a much more detailed discussion here:
https://github.com/MikeBishop/dns-alt-svc/issues/105.
https://github.com/MikeBishop/dns-alt-svc/issues/60
https://github.com/MikeBishop/dns-alt-svc/issues/58

* The introduction talks about SVCB 'provid[ing] clients with complete
> instructions for access to an origin.' 'origin' is a Web-specific term; is
> there a more neutral term you can use to distinguish it from HTTPS? I see
> in Terminology that you justify this for alignment with Alt-Svc, but that
> seems to assume that other protocols will have an origin concept -- in
> particular, a scheme (I'm not against aligning all potential protocols to
> this model, just a bit surprised that it's got this far).
>

SVCB is designed for use with URIs, so a scheme is required.  (Section 10,
"The scheme SHOULD have an entry in the IANA URI Schemes Registry".)  URIs
that concern a domain name presumably have an "authority" in their URI that
contains a "host", and might contain a "port".

If you can think of a better name for "scheme, host, and
port-if-applicable", we can certainly adjust.

> * That brings to mind the SRV framework; is there any attempt to relate
> the SVCB framework to it -- especially since this appears to embed the ALPN
> view of the world? I'm sure some will want to know...
>

There's no explicit connection to SRV.  Personally, I view SVCB as a
successor to SRV, but it's certainly not intended to replace SRV where SRV
is already working well.

* Did you consider publishing these as two separate documents? That might
> make the layering more clear.
>

It would of course be possible to separate them, but I think it might be
confusing, because SVCB's design choices are easiest to understand in the
context of a realistic example, and HTTPS is the only example that is
initially specified.

* Do we have statements of support for the delegation use cases from client
> implementers? This was a key purpose for Alt-Svc, but it wasn't implemented
> by clients widely.
>

I believe we do.

* Section 7.5 gives the HTTPS record effective HSTS semantics. Has there
> been engagement with / review from the security community on this?

I would say so, e.g. https://github.com/MikeBishop/dns-alt-svc/issues/87

> In particular:

TTL is not strictly relevant here.  Unlike the HSTS header, this semantic
works perfectly well even with TTL=0.  The HSTS header relies on the user
having had a "clean network path" in the (recent) past.  The HTTPS-upgrade
here instead relies on the user currently having a "clean DNS path", e.g.
inside DoH.

  * Are there any other fixes / enhancements to HSTS that we want to layer
> in?

Suggestions welcome!

> > To: Benjamin Schwartz <[email-masked]>, Erik Nygren <
> [email-masked]>, Mike Bishop <[email-masked]>
> >
> >
> >
> > Htmlized:
> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sConsider a
> "mandatory" key rangesvcb-https
> >
> >
> > Abstract:

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Jun 2020 13:25:01 +1000

On Thu, Jun 25, 2020, at 12:20, Ben Schwartz wrote:
> SVCB is designed for use with URIs, so a scheme is required. (Section 
> 10, "The scheme SHOULD have an entry in the IANA URI Schemes 
> Registry".) URIs that concern a domain name presumably have an 
> "authority" in their URI that contains a "host", and might contain a 
> "port".

I think that you have (correctly) scoped this to services that are identified by a URI that also has an authority containing a domain name.  However, the port part is not central.  What is central is that these are services and not origins.

The core definition of SVCB does not depend on the classic web origin concept.  This is largely because inclusion of a port number is not central to the definition.  Though it does establish a pattern for extending the attr-label with _port, that is a per-scheme choice.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Jun 2020 09:59:39 +1000

Large test deployments can also be done with private values.  Been there, done that.  If the wire format remains stable you just tweak the type code value once it is assigned.  If it doesn’t then you don’t have interop problems with the old wire format.

Changing wire format of a allocated type should NEVER be done.  That is a real headache for everybody.  I’ve seen early allocation do this and it is not nice.

Mark

> On 24 Jun 2020, at 09:40, Tommy Pauly <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Jun 2020 09:38:14 +1000