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 <p...@redbarn.org
<mailto:p...@redbarn.org>> wrote:
httpssvc is not an alternate service description permitting
fallback to the non-alternative; 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.
"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:>
On 10/03/2020 19:11, Paul Vixie wrote:
On Tuesday, 10 March 2020 19:05:39 UTC Stephen Farrell wrote:
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
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.
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.
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:-)
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...
https://tools.ietf.org/html/draft-ietf-quic-manageability-06#section-3
....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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
