Subject: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt

From: [email-masked]
Date: Mon, 09 Mar 2020 13:10:07 -0700

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 HTTPSSVC)
        Authors         : Ben Schwartz
                          Mike Bishop
                          Erik Nygren
	Filename        : draft-ietf-dnsop-svcb-httpssvc-02.txt
	Pages           : 36
	Date            : 2020-03-09

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".

   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-httpssvc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-02
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-httpssvc-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-httpssvc-02

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/

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Mar 2020 16:56:39 -0400

It occurs to me that I hit "publish" on this draft without updating the
release notes, so I'll mention some of the many changes since -01 here
instead:

 - All changes to Alt-Svc have been removed.  I would like to see some
updates to Alt-Svc, but since this draft is now in DNSOP, and any changes
to Alt-Svc are going to require a long discussion, we've removed them from
this draft and will consider them separately in the future.
- The examples have been expanded and reorganized.
- Priority zero is now the definition of AliasForm, instead of being
reserved for AliasForm.
- Repeated SvcParamKeys are no longer allowed.
- The "=" sign may be omitted in a key=value pair if the value is also
empty.
- In the wire format, SvcParamKeys must be in sorted order.
- New text regarding how to handle resolution timeouts (clients must fail
hard to avoid a downgrade attack)
- Expanded description of recursive resolver behavior
- Much more precise description of the intended ALPN behavior
- Match the HSTS specification's language on HTTPS enforcement
- Removed 'esniconfig=""' mechanism and simplified ESNI connection logic

As always, please review and send comments.  We also expect to do a
presentation on this draft (remotely) in the DNSOP session.

On Mon, Mar 9, 2020 at 4:12 PM <[email-masked]> wrote:

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Mar 2020 02:32:05 +0000

On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
>  ...

i propose that section 6.2 for "port", and all references to same, be removed. 
this is:

---

6.2.  "port"

   The "port" SvcParamKey defines the TCP or UDP port that should be
   used to contact this alternative service.

   The presentation format of the SvcParamValue is a numeric value
   between 0 and 65535 inclusive.  Any other values (e.g. the empty
   value) are syntax errors.

   The wire format of the SvcParamValue is the corresponding 2 octet
   numeric value in network byte order.

===

in the SRV RR (from RFC 2782) we specified a port number as part of the RData 
because a client would otherwise have to have an up-to-date /etc/services file 
(or local equivalent) to know what (TCP) port number a listener would listen 
on, and this seemed archaic.

for HTTPSSVC and SVCB, the service is a constant (HTTPS) and its transport 
layer port number (443) is known. inviting listener operators to specify a 
different port number will result in unpredictable (other than wide-spread) 
failures for those accessors behind NAT, firewalls, or ALG's.

please leave out this legacy from DNS SRV as you go forward with HTTPSSVC.

-- 
Paul

---

From: Erik Nygren <[email-masked]>
Date: Mon, 9 Mar 2020 22:42:01 -0400

> i propose that section 6.2 for "port", and all references to same, be

We discussed this some on one of our authors' calls following
my seeing you allude to this a few weeks ago.

The rationale for keeping port is that HTTPS is not just about the "web"
use-case.
While for Web use-cases it is common for most things to always tcp/443,
there
are plenty of non-"Web" use-cases (such as API calls in data centers,
service meshes, etc.)
where non-standard ports are commonly used.  I know that Tim keeps
highlighting
a desire to make sure we consider these use-cases.

There's a default when port is left out (perhaps that should be clarified
better?)
but there are cases when being able to switch to an alternate port has
value.
Another case where this applies is QUIC/UDP where udp/443 is commonly
used but where operators may wish to situationally use different ports.

Adding a warning that the use of non-default ports could have
operational challenges might be warranted.  (There are also
some confused deputy risks around non-default ports for servers
that don't validate the port in the Host header, but others convinced
me that that's a problem for another day.)

A closely related issue is this one:

https://github.com/MikeBishop/dns-alt-svc/issues/111

(regarding clarifying the default port.)

Does this help address the concern?
It's helpful to know the historical context.

       Erik

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Mar 2020 03:16:35 +0000

> a desire to make sure we consider these use-cases.

that seems fair, but still somewhat risky. many times in the last year i've 
been told by people younger than me that accessing the internet from beyond 
the horizon of the far end is old-think and should die. somehow we have to 
avoid that culture war, because family, corporate, and sensitive/military 
networks will always exist, and with them, NAT, ALG, and firewalls.

> used but where operators may wish to situationally use different ports.

how can we properly inform those operators that if their audience is broader 
than their own cloud or data center, that is, including distant edge networks 
which are managed and private, that anything they offer on a non-default port 
will be unreachable, and often silently so?

i can't defend and won't try to defend authoritarian public networks nor 
surveillance capitalism in internet service providers. that's not my concern. 
rather, it's the managed private edge network whose utility i'd like to 
preserve, without a generation of finger-pointing from what won't work in 
HTTP/3 because of differing basic assumptions.

> operational challenges might be warranted.  (...)
> 

issue 111 seems unrelated. what i'm trying to avoid is service operators 
trying to be reachable on port numbers that managed private networks at the 
remote edge won't recognize and so won't build flow-state for. so, warnings as 
to possible unreachability of non-default ports sound like a good starting 
point. but i think we need to do more.

i am extremely worried about QUIC manageability, as described here:

https://tools.ietf.org/html/draft-ietf-quic-manageability-06#section-3

this draft carefully enumerates, and eliminates, every potential method by 
which a remote-edge managed private network operator might be able to 
recognize a permitted (in-policy) flow. i feel like this is our last 
opportunity to set expectations about unrecognizable traffic, and to agree on 
some norm by which service operators can act willfully to be reachable.

if i'm addressing the wrong audience, or you'd like to follow up 1x1, let me 
know and i'll adapt my signal pattern for these concerns. 

-- 
Paul

---

From: Patrick McManus <[email-masked]>
Date: Tue, 10 Mar 2020 09:30:53 -0400

another positive feature of ports in this record is that it provides some
address space independent of the origin security model of the URI. By this
I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555
are different origins with different web security boundaries. While two
different httpssvc records for 443 and 555 (both for  https:// www.foo.com)
are in the same origin.. this level of indirection can be used for A/B
testing or even for encoding load balancing information in a IP constrained
space. Just like the address is distinct from the URL, the port separates
the 'what' from the 'how' and that's good.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Mar 2020 16:24:38 +0000

> the 'what' from the 'how' and that's good.

your reply above precisely demonstrates the risk offered by allowing a service 
operator to select a non-default port. please read my down-thread response to 
erik nygren and consider the non-reachability impacts of such selection on far 
edge managed private networks, who will only build NAT, AGM, or firewall flow 
state for permitted (in-policy) flows.

there's a separate problem on retermination, but i'll address that in quic-wg.

-- 
Paul

---

From: Patrick McManus <[email-masked]>
Date: Tue, 10 Mar 2020 14:25:57 -0400

alt-svc is quite robust to reachability failures of the alternative origins
should some client find itself on a network that filters full transit.

This process is already existing technology (rfc 7838). From that
perspective the DNS record is just a way to bootstrap it over DNS rather
than the default host/port for the URI.

-Patrick

---

From: Erik Nygren <[email-masked]>
Date: Tue, 10 Mar 2020 14:48:07 -0400

We should also look at how and where we want to separate operational
guidance from what mechanisms are available.  Ideally we'd minimize
foot-guns
(hence the inclusion of a default transport, at least for the HTTPS
use-cases)
and we should have safe defaults, but I'm not sure to what degree
we want to prohibit people from configuring things that may make
sense in particular operational contexts.

(I keep pondering if we need an "HTTPOPS" working group to provide guidance
on topics like this, but I'm not sure we want to tackle that problem in
this draft.  ;-)

   Erik

On Tue, Mar 10, 2020 at 2:26 PM Patrick McManus <[email-masked]>
wrote:

> alt-svc is quite robust to reachability failures of the alternative
> origins should some client find itself on a network that filters full
> transit.
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Mar 2020 18:54:29 +0000

> than the default host/port for the URI.

your reply makes it seem that i've stepped into a Narrative. nothing in rfc 
7838 describes a risk reduction against the httpssvc "port" parameter leading 
a service operator to put something on an "alternative origin" whose port 
number will be broadly unrecognized by far end managed private networks, which 
would prevent flow-state creation, thus creating black holes. httpssvc is not 
an alternate service description permitting fallback to the non-alternative; 
httpssvc is the service description itself. any non-default port used there 
will have reachability that is exactly proportional to locality.

-- 
Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2020 19:05:39 +0000

Paul,

On 10/03/2020 18:54, Paul Vixie wrote:
> the httpssvc "port" parameter leading 
> would prevent flow-state creation, thus creating black holes

Sorry, I'm missing something here.

What's the difference between having a port number
as part of HTTPSSVC (or whatever we call it;-) in
the DNS and having a web page on 443 that includes
hrefs with https:// schemed URLs that are not using
port 443?

Thanks,
S.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Mar 2020 19:11:12 +0000

> hrefs with https:// schemed URLs that are not using

technically, very little. practically, one of them doesn't solve the problem 
addressed by ANAME, and the other does. so we can expect ubiquitous deployment 
for HTTPSSVC, with a non-modal knowledge spectrum among deployers.

-- 
Paul

---

From: Patrick McManus <[email-masked]>
Date: Tue, 10 Mar 2020 15:24:26 -0400

On Tue, Mar 10, 2020 at 2:54 PM Paul Vixie <[email-masked]> wrote:

> httpssvc is not
> httpssvc is the service description itself.
>

7.2.  Relationship to Alt-Svc

   Publishing a ServiceForm HTTPSSVC record in DNS is intended to be
   similar to transmitting an Alt-Svc field value over HTTPS, and
   receiving an HTTPSSVC record is intended to be similar to receiving
   that field value over HTTPS.

no-one would use this for h3 if that were not the case.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2020 19:24:58 +0000

Hiya,

On 10/03/2020 19:11, Paul Vixie wrote:
> addressed by ANAME, and the other does. 

Sorry, let me try again. HTTPSSVC might include a port
option or not. If it does, then traffic will use that as
the destination port. If it does not, and someone prefers
not to use 443 for their server, they'll just do one more
HTTP roundtrip. (They'll likely need to support that HTTP
30x anyway for non-HTTPSSVC aware clients). ISTM the end
result is the same traffic heading to the non-443
destination port, but, in the 2nd case, with one gratuitous
interaction on port 443.

I don't get why that distinction is meaningful for the
operator of the network containing the browser, which is
where I understood your concern lies.

> so we can expect ubiquitous deployment 
> for HTTPSSVC, 

Browser support for https on other ports is already there
so not sure why that matters.

> with a non-modal knowledge spectrum among deployers.

I also don't understand what you mean by that last.
(I do have a guess, but not a confident one:-)

Cheers,
S.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 13 Mar 2020 22:14:22 -0700

i'm replying to two messages here, one from patrick, one from stephen.

Patrick McManus wrote on 2020-03-10 12:24:
> 
> On Tue, Mar 10, 2020 at 2:54 PM Paul Vixie <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> httpssvc is not an alternate service description permitting
>> fallback to the non-alternative; httpssvc is the service
>> description itself.
> 

"intended to be similar" is not a specification. it will be possible in
an HTTPSSVC world to put a non-standard port into the RDATA, and to have
a web client contact a web server without ever using TCP port 443. i
know that there is language describing the TCP port 443 fallback, but
there is no way to enforce that. so while an alt-svc meta header might
be equivalent to HTTPSSVC in some logical sense, the HTTPSSVC makes the
TCP port 443 service only-theoretically-required rather than the alt-svc
meta header situation where it is very-definitely-required.

in practical terms, we are headed for a world where a webmaster can
think that non-default port numbers on TCP or on UDP will just work, and
may not have a way to measure the cases where it doesn't work. in
practice (from the client's point of view) those web sites will simply
be black holes. first-mover advantage would determine the long term
outcome. thus my first suggestion was to remove the port number from the
HTTPSSVC RDATA. the pushback was, "this may be useful in clouds where
the default port isn't necessary and won't be used."

so now i'm wondering exactly where to document this well enough that the
TCP port 443 fallback, and a UDP port 443 fallback if HTTP/3 is
available, are always present. because otherwise, anyone surfing from
behind a NAT, ALG, or firewall will be silently removed from the
audience. i hope you'll agree that we should strive together to avoid
that risk. "let the market decide" is not a path to that outcome.

---

Stephen Farrell wrote on 2020-03-10 12:24:>
>>> What's the difference between having a port number as part of
>>> HTTPSSVC (or whatever we call it;-) in the DNS and having a web
>>> page on 443 that includes hrefs with https:// schemed URLs that
>>> are not using port 443?
>> 
>> technically, very little. practically, one of them doesn't solve
>> the problem addressed by ANAME, and the other does.

i apologize for my excessive brevity. the implication i was drawing here 
is that the audience for HTTPSSVC includes all ANAME use cases, which is 
vastly larger than the audience for ALT-SVC. so a solution which won't 
be under-deployed or misunderstood by the ALT-SVC audience might be very 
broadly under-deployed or misunderstood by the prospective HTTPSSVC 
audience.

> Sorry, let me try again. HTTPSSVC might include a port option or not.
> If it does, then traffic will use that as the destination port. If it
> does not, and someone prefers not to use 443 for their server,
> they'll just do one more HTTP roundtrip. (They'll likely need to
> support that HTTP 30x anyway for non-HTTPSSVC aware clients).

i agree that support for non-HTTPSSVC aware clients will be important to 
webmasters. however, that's a short-term expedient. just as google 
periodically declares it will no longer answer requests from browsers 
more than a dozen years old, so it will be that technology evolution 
will eventually marginalize the importance of non-HTTPSSVC aware clients.

> ISTM the end result is the same traffic heading to the non-443
> I don't get why that distinction is meaningful for the operator of 
> the network containing the browser, which is where I understood your 
> concern lies.

i'm glad we're discussing this, because the matters at stake here are 
both important and subtle. my concern is about configurations which 
appear to the webmaster to be functional, including where there is no 
fallback service on TCP/443 or UDP/443, but traffic "seems normal", and 
the audience who can only reach those "fallbacks" is disconnected. we 
know from 25 years of commercialization and privatization that affected 
users will complain to their local sysadmins and not the distant 
webmasters. that's why the policy of both source and sink are conjoined.

> I also don't understand what you mean by that last. (I do have a
> guess, but not a confident one:-)

better than i explained in the first place than that you have to guess. 
(again, my apologies, i fought the words, and this time i won so they lost.)

ALT-SVC deployers are mostly experts. they read documentation and 
specifications; they understand what's going on, and they know what are 
the implications of any shortcut they may make. especially, they know 
which shortcuts would bypass unenforceable norms, and they pay special 
attention to those.

HTTPSSVC deployers will not mostly be experts. some will be, but the 
spectrum from low expertise to high expertise will be fairly even. we 
should therefore as we specify and as we document, remove features which 
may lead to confusion and finger-pointing, or where removal is not 
possible, we should try to add enforcement mechanisms so that any 
failure to observe norms will be quickly apparent to the team who can do 
something about it. if neither removal nor enforcement are possible, 
then we should figure out how our messaging will limit these risks.

===

for context, i surf the web from beyond its horizon. there is always 
either a NAT, an ALG, or a firewall, or all three, between my sensitive 
personal information and the outside world. this is true for a lot of 
power users and their families, and for most private corporate networks, 
and for all sensitive (military or intelligence) networks.

because QUIC is designed to be unidentifiable according to...

...i am very concerned that my only way to enforce policy in an HTTP/3 
world will be to send everything through an ALG (so, an HTTPS or SOCKS 
proxy). this would be a privacy nightmare that i'll go to some expense 
to avoid. i plan therefore to permit UDP/443 anywhere i currently permit 
TCP/443, blocking only those server IP's also known to support DoH or 
some other policy-violating service such as hosting drive-by malware or 
content which is illegal in my jurisdiction or which violates regulatory 
policy for my industry.

this means i really need your proposed norm where TCP/443 is always 
available as a fallback, to remain true not just in the short term, but 
for the indefinite future. removing the port number from the HTTPSSVC 
RDATA is one way to do that, since the ALT-SVC meta headers would then 
only be ineffect if the webmaster _does_ run an TCP/443 service. if the 
HTTPSSVC team thinks that the port# parameter is vital, i can hardly 
argue that you're wrong. but i will ask for help finding other ways to 
avoid disenfranchisement of users on managed private networks.

thank you for reading what feels like a very overlong response.

-- 
P Vixie