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

On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie <paul@redbarn.org> wrote:

> On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> > 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:
> >
> >  ...
> >
> > As always, please review and send comments.  We also expect to do a
> > presentation on this draft (remotely) in the DNSOP session.
>
> i propose that section 6.2 for "port", and all references to same, be
> removed.
>

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

> 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
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>