Subject: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

From: Erik Nygren <[email-masked]>
Date: Tue, 24 Sep 2019 09:21:25 -0400

Following the discussions in Montreal (as well as with some of the ESNI
authors),
we refactored the HTTPSSVC draft to make it more general.  The hope is that
it could be an alternative (or replace the need) for a distinct ESNI record.
The draft generalizes to a protocol-agnostic SVCB record, but also specifies
an HTTPSSVC record for the HTTP(S) use-case.

Based on discussions with various chairs, the plan is to call for adoption
in the DNSOP WG.

Comments/feedback are most welcome.

      Erik

---------- Forwarded message ---------
From: Erik Nygren <[email-masked]>
Date: Tue, Sep 24, 2019 at 9:17 AM
Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
To: dnsop WG <[email-masked]>, Ben Schwartz <[email-masked]>, Mike
Bishop <[email-masked]>

Following discussions around the "HTTPSSVC" record proposal in Montreal
with the DNSOP, HTTP and TLS WGs, we've updated what was previously
"draft-nygren-httpbis-httpssvc-03".  The new version is
"draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
feedback from the WG discussions, as well as feedback from discussions with
the TLS WG (as we'd like to see this replace the need for a separate ESNI
record).

In particular, it generalizes the record into a new "SVCB" record which
doesn't have any protocol-specific semantics.  It also defines an
"HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
parameter registry) and which defines the HTTP(S)-specific semantics such
as bindings to Alt-Svc.  Other protocols can either define bindings
directly to SVCB or can define their own RR Type (which should only ever be
needed if there is a need to use the record at a zone apex).

We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs
can go against:  https://github.com/MikeBishop/dns-alt-svc

Major changes from "draft-nygren-httpbis-httpssvc-03" include:

* Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the
HTTPS-specific functionality and text to its own portion of the document).
* Elimination of the SvcRecordType field (and making the SvcRecordType
implicit)
* Changing the wire format of parameters from being in Alt-Svc text format
to a more general binary key/value pair format (with a mapping to Alt-Svc
for HTTPSSVC).
* Adding optional "ipv4hint" and "ipv6hint" parameters.
* Quite a few cleanups and clarifications based on input (and we
undoubtedly have more left to go)

This retains support for all of the use-cases that the previous HTTPSSVC
record had (such as for covering the ANAME / CNAME-at-the-zone-apex
use-case).

Feedback is most welcome.  If the TLS WG is going to use this instead of a
separate ESNI record, there is a desire to make progress on this fairy
quickly.

       Erik

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Sep 23, 2019 at 7:01 PM
Subject: New Version Notification for
draft-nygren-dnsop-svcb-httpssvc-00.txt
To: Mike Bishop <[email-masked]>, Erik Nygren <[email-masked]>,
Benjamin Schwartz <[email-masked]>

A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:           draft-nygren-dnsop-svcb-httpssvc
Revision:       00
Title:          Service binding and parameter specification via the DNS
(DNS SVCB and HTTPSSVC)
Document date:  2019-09-22
Group:          Individual Submission
Pages:          33
URL:
https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt
Status:
https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/
Htmlized:
https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc

Abstract:
   This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
   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 keying material for encrypting TLS SNI).  They also
   enable aliasing of apex domains, which is not possible with CNAME.
   The HTTPSSVC DNS 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: The specific name for this RR type is an open topic
   for discussion.  "SVCB" and "HTTPSSVC" are meant as placeholders as
   they are easy to replace.  Other names might include "B", "SRV2",
   "SVCHTTPS", "HTTPS", and "ALTSVC".

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: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Sep 2019 14:27:48 +0000

*   we refactored the HTTPSSVC draft to make it more general.  The hope is that
  *   it could be an alternative (or replace the need) for a distinct ESNI record.

I am strongly opposed to two ways of doing the same thing.  I will be taking a close look at this, but I hope that the folks heavily involved with ESNI see what changes, if any, need to be made to use this.

  *   We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs can go against:  https://github.com/MikeBishop/dns-alt-svc<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_MikeBishop_dns-2Dalt-2Dsvc&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=tx3JL_P4GWN_yvVV7GJ3vxSQ_HrZ-KEdkfVWWtEy7rk&s=649CY0JbaYZmTqIiJlM05R9i9kMrcyYFjaPp2XnI9zk&e=>

  *   URL:            https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dnygren-2Ddnsop-2Dsvcb-2Dhttpssvc-2D00.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=tx3JL_P4GWN_yvVV7GJ3vxSQ_HrZ-KEdkfVWWtEy7rk&s=z4EtrFtjyct4U90Ybv0Pp0V20JFDjMD0YjMrWj2_YkM&e=>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Sep 2019 15:32:34 +0100

Hi Erik,

FWIW, if browsers preferred this to an ESNI RR and
we could forget the ESNI RR then I'd be ok with that.
I'm not clear if they do or not though. In the meantime,
assuming this went ahead instead of or in addition
to an ESNI RR, I've a few questions below...

> it could be an alternative (or replace the need) for a distinct ESNI record.

So I think the basic ESNI case where there's no
name changes nor alt-svc etc would be as below in
presentation syntax, am I reading that right?

   example.com. 7200  IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )

I'm also not clear if that's the exact same as:

   example.com. 7200  IN SVCB 0 . ( esnikeys="/wHrAh..." )

...is it? If so, which'd be preferred or would
clients be expected to be able to handle both?
And I don't get why two ways to say the same thing
are useful.

Secondly, ESNIKeys currently supports versions,
multiple keys, cipher_suites, extensions and even
dns_extensions. And we could have >1 rrdata for
ESNI or for SCVB/HTTPSSVC.

Would you envisage adoption of SVCB/HTTPSSVC meaning
that we could drop some of the generality that's
present in ESNIKeys? If so, what?

I'd like if ESNIKeys were made simpler FWIW, so if
this had that effect, then I'd be more for it. If,
OTOH, this just added complexity (for a library
implementing ESNI), which currently seems to be the
case, then it'd be less attractive, to me at least.
(I guess I'm agreeing with Rich there:-)

Thanks,
S.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 24 Sep 2019 11:15:39 -0400

>    example.com. 7200  IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )

For HTTPSSVC, the "alpn" parameter is mandatory (Section 7.2), so the
minimal record is

example.com. 7200  IN HTTPSSVC 0 . alpn=h2 esnikeys="/wHrAh..."

> And I don't get why two ways to say the same thing

SVCB records are always on underscore-prefixed names, and are prohibited
for HTTP or HTTPS.  However, if you have a protocol called "example" that
runs over TLS, you could publish a record like

_8080._example.example.com 7200  IN SVCB 0 . esnikeys="/wHrAh..."

(This would require the "example" protocol to define an SVCB binding.)

> present in ESNIKeys? If so, what?

The dns_extensions field is in ESNIRecord, not ESNIKeys, so that is
excluded.  I wasn't expecting to remove any of the other fields.

> (I guess I'm agreeing with Rich there:-)

I imagine a TLS library implementation of ESNI taking an IP address, an
SNI, and an ESNIKeys struct, as input to connection initiation.  In that
model, the choice of DNS representation has no effect on the library.

An HTTP client [library] that is using such a TLS library would be
responsible for performing the requisite DNS resolution.  This is indeed
more complex than the proposed ESNI RR type, but I believe it's a more
logically sound match for the HTTP origin model, and offers several
concrete benefits (such as triggering HTTP->HTTPS upgrade).

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Sep 2019 18:31:48 +0300

> Title:          Service binding and parameter specification via the DNS

Couple comments:

- Is there need for two resource records? It seems like the two uses
  could be distinguished by starting point.
- What about starting point of protocols that have defined name for
  SRV records? That thing is of form _foo._tcp.domain.example
  (or _foo.udp.domain.example).
- One possible use for AliasForm with '.' would be to signal that
  this service does not exist (IIRC, some other rrtype had special
  "this does not exist" value).
- It seems like ALPN and port are fundamential and would be better
  being their own fields, instead of attributes.
- This could be defined to carry out TLS upgrade for any protocol
  that uses it. However, one would need to allow ALPN to override the
  behavior (e.g., HTTP/3 needs to change transport from TCP to UDP).
- To me, ipv4hint/ipv6hint seem very bad ideas, as they break
  normalization and ownership, drastically increasing odds for errors.
- I would not speculate about records for DNS authorities looking
  anything like this. That RRtype will be very special snowflake.

-Ilari

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 24 Sep 2019 08:40:14 -0700

> On Sep 24, 2019, at 7:32 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Erik,
> 
> I'm not clear if they do or not though.

Regarding the status of which RR we use, I think the main goal for a system (speaking as an operating system vendor, rather than specifically just a browser vendor) would be to minimize the number of records we need to look up in order to get a usable set of information for connecting. To that end, I appreciate the generality and extensibility of the SCVB approach. It should ideally include any functionality needed for an ESNI-only deployment, but also allow for the specification of alt-svc, as well as other extensions that may come in the future.

Thanks,
Tommy

> In the meantime,
>   example.com <http://example.com/>. 7200  IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )
> 
>   example.com <http://example.com/>. 7200  IN SVCB 0 . ( esnikeys="/wHrAh..." )
> 
> <0x5AB2FAF17B172BEA.asc>_______________________________________________
> TLS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Sep 2019 16:50:31 +0100

Thanks Ben, bit more below...

On 24/09/2019 16:15, Ben Schwartz wrote:
> for HTTP or HTTPS. 

Thanks. I must've missed that in reading. Might be
worth saying that more explicitly and maybe giving
such examples.

> The dns_extensions field is in ESNIRecord, not ESNIKeys, 

Sorry, you're right.

> so that is

Pity;-) In any case, that means that there could still
be scenarios where we have something like:

 example.com. 7200  IN HTTPSSVC 0 . alpn=h2 esnikeys="/wHrAh..."
 example.com. 7200  IN HTTPSSVC 0 . alpn=h2 esnikeys="/wHEdf..."

That could be because of variations within the ESNIKeys
structure (e.g. version, or extensions, or differing
groups or whatever). I'm not sure that randomly picking
one of those is going to work, e.g. if a library doesn't
support all the versions a server supports then the
https client would have to cycle through 'em or something
which seems a bit ickky.

> model, the choice of DNS representation has no effect on the library.

Not quite though. If there's anything inside ESNIKeys that
the application may need to know about, or if the API needs
to support >1 input ESNIKeys, I'd say it gets messier.

If we didn't end up needing the ESNI RR at all, I wonder if
it'd be better to move the versioning out of ESNIKeys entirely
(i.e. have the SvcParamKey be something like "esnikeys05" for
the next ESNI draft and finalise that when ESNI is done) and
maybe also radically simplify ESNIKeys as much as can be done.

> concrete benefits (such as triggering HTTP->HTTPS upgrade).

Possibly so. I'll be interested when folks who implement
browsers and HTTP libraries say what they think.

Cheers,
S.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 24 Sep 2019 12:24:15 -0400

>   could be distinguished by starting point.

I believe you're right that a single RR type would suffice, but that RR
type specification would have to contain special-case logic for HTTP and
HTTPS.  We felt it was more elegant to have one purely generic RR type, and
one specialized.  Also, if any other protocol wants an SVCB-compatible type
without prefixing, we'll end up with multiple RR types anyway.

If the WG would prefer a single RR type with a special-case for HTTP(S), I
think we would be able to make that change.

>   (or _foo.udp.domain.example).

Do you mean to ask about how this would coexist with SRV?  Broadly, I view
this as a successor to SRV, but I think the details of how they interact
would have to be defined by the protocol mapping document for a specific
protocol that currently uses SRV.  The correct logic might be different for
different protocols; I'm not sure.

If you think there's a universal rule, that would be good to know.

>   "this does not exist" value).

Currently, that's effectively indicated by NXDOMAIN/NODATA.  Do you see a
need for a specific flag?

>   being their own fields, instead of attributes.

ALPN only applies to TLS-based protocols, and even many TLS-based protocols
don't use it.  For example, a hypothetical mapping of SVCB for SSH would
have no use for ALPN.

I agree that ports are nearly universal, but they're often redundant.  For
example, in HTTPSSVC, the port can be omitted if it is the default port.
Since the port doesn't apply in the AliasForm, making it a parameter seemed
like the most convenient representation.

>   behavior (e.g., HTTP/3 needs to change transport from TCP to UDP).

Yes, SVCB is well-suited for pre-connection "upgrades" of all sorts, and
hopefully it will be useful for TLS upgrades beyond HTTP.  As you note,
this can be nontrivial, as in the case of HTTP, where the ALPN can signal a
transport change!  For that reason, the details of client behavior are left
to the protocol mappings.

>   normalization and ownership, drastically increasing odds for errors.

I admit that these hints are fragile, but they have been a very strong
request from some browser vendors, and similar hints are also present in
the ESNI RR proposal.  The concern is that, when the origin is using
HTTPSSVC delegation, and the client's recursive is not HTTPSSVC-aware, the
client will have to perform a followup A+AAAA query before it can start
connecting.  The IP hints allow connection start right away.

The draft contains a number of mitigations against fragility.  For example,
the client is still required to perform the A+AAAA queries, and switch to
one of those "official" IP addresses as soon as they are available.
Hopefully this limits the amount of mischief that can be made by bad IP
hints.

>   anything like this. That RRtype will be very special snowflake.

I agree, we should probably remove that.  Hopefully many of the SVCB
conventions will be reusable, but it's too soon to say.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Sep 2019 21:11:55 +0300

> different protocols; I'm not sure.

I mean more of the starting point to use for protocols that already use
SRV.

> need for a specific flag?

Well, NODATA could work (except for http(s)://foo.example).

> don't use it.  For example, a hypothetical mapping of SVCB for SSH would

Some sketch-on-napkin stuff I did actually had subprotocol in place of
ALPN, with subtly different meaning (but most of the time it goes
directly to ALPN).

And I have dealt with hacky SSH over TLS (or worse, TELNET over TLS),
and both did use ALPN.
 
One major issue nowadays is that SSH does not have any equivalent of
SNI (I have seen setups where that would have been very useful).

> like the most convenient representation.

Some sketch-on-napkin stuff I did had port 0 mean "default/as-specified"
(because it is not like you can use port 0 with APIs as they are).
 
> to the protocol mappings.

Obviously if the ALPN is something unknown, one can not connect, as the
semantics are unknown.

And yes, most protocols could not deal with transport change.

> Hopefully this limits the amount of mischief that can be made by bad IP

I do not regard ESNI spec as example of good design. One way to mitigate
potential problems would be to only honor IPhint fields if target is .
(self). That would still leave things unnormalized but at least fix the
issues with ownership.

> conventions will be reusable, but it's too soon to say.

I have some ideas (but no idea just how badly those would break DNS),
and they look pretty much nothing like SVCB. But that is in scope of
DPRIVE, not TLS nor HTTPBIS.

-Ilari

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 27 Sep 2019 09:00:57 -0700

On Tue, Sep 24, 2019, at 7:27 AM, Salz, Rich wrote:
> I am strongly opposed to two ways of doing the same thing. I will be 
> taking a close look at this, but I hope that the folks heavily involved 
> with ESNI see what changes, if any, need to be made to use this.

Indeed! We are watching this with interest. I also prefer a single way of doing things. :-)

> 
> 
>  * We'd like to see this adopted by the DNSOP WG. Until then, issues 
> and PRs can go against:  https://github.com/MikeBishop/dns-alt-svc 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_MikeBishop_dns-2Dalt-2Dsvc&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=tx3JL_P4GWN_yvVV7GJ3vxSQ_HrZ-KEdkfVWWtEy7rk&s=649CY0JbaYZmTqIiJlM05R9i9kMrcyYFjaPp2XnI9zk&e=>
>  *  URL:  
> https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dnygren-2Ddnsop-2Dsvcb-2Dhttpssvc-2D00.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=tx3JL_P4GWN_yvVV7GJ3vxSQ_HrZ-KEdkfVWWtEy7rk&s=z4EtrFtjyct4U90Ybv0Pp0V20JFDjMD0YjMrWj2_YkM&e=>
>