Subject: [DNSOP] port number in HTTPSSVC

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Jan 2020 18:23:53 +0000

in SRV we added a port number to the rdata because the /etc/services file was 
painful to keep globally updated. SRV was protocol independent.

HTTPSSVC is protocol specific, and when it copied SRV, it included the port 
number in the rdata, which i think is both unnecessary and error-prone.

managed private networks who want to permit outbound HTTP/3 are going to add a 
rule like "if the far end port number is 443, add a stateful rule". anyone who 
uses the port number field (if it exists) in HTTPSSVC to specify a different 
port number is going to suffer, as will many of the clients trying to access 
that service.

i suggest that the port 443 assumption for HTTP/3 be baked in, and that this 
field be removed from the HTTPSSVC rdata.

-- 
Paul

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 3 Jan 2020 14:32:58 -0500

HTTPSSVC co-editor here.

The effect of this change seems similar to deprecating support for
non-default ports in HTTP/3.  While I have some misgivings about the
handling of non-default ports in HTTPS, I would want to see consensus in
the HTTP and QUIC working groups before making this change.

I would suggest sending your proposal to those lists, and we can adjust the
HTTPSSVC draft based on their conclusions.

On Fri, Jan 3, 2020 at 1:24 PM Paul Vixie <[email-masked]> wrote:

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

---

From: Erik Kline <[email-masked]>
Date: Fri, 3 Jan 2020 12:01:04 -0800

I think removing port number flexibility might unduly constrain some data
center use cases where service reachability might not have the more common
443-only limitations.

On Fri, Jan 3, 2020 at 11:33 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> I would suggest sending your proposal to those lists, and we can adjust
> the HTTPSSVC draft based on their conclusions.
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jan 2020 12:29:57 -0800

I agree. I do not think we should make this change.

-Ekr

On Fri, Jan 3, 2020 at 12:02 PM Erik Kline <[email-masked]> wrote:

> [email-masked] <[email-masked]>> wrote:
>
>> HTTPSSVC co-editor here.
>>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Jan 2020 21:01:28 +0000

> center use cases where service reachability might not have the more common

"think" and "might" are unpersuasive, and "unduly" is subjective. however, 
i'll explain further on the other mailing list that the HTTPSSVC co-chair 
directed me to.

-- 
Paul

---

From: Christian Huitema <[email-masked]>
Date: Fri, 3 Jan 2020 11:10:02 -1000

Most of the early tests of QUIC were using port 4433, not 443. Using
alternate ports for testing is very common.

-- Christian Huitema

On 1/3/2020 10:01 AM, Erik Kline wrote:
> I think removing port number flexibility might unduly constrain some
> data center use cases where service reachability might not have the
> more common 443-only limitations.
>
> On Fri, Jan 3, 2020 at 11:33 AM Ben Schwartz
> <bemasc=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     HTTPSSVC co-editor here.
>
>     non-default ports in HTTP/3.  While I have some misgivings about
>     the handling of non-default ports in HTTPS, I would want to see
>     consensus in the HTTP and QUIC working groups before making this
>     change.
>
>     I would suggest sending your proposal to those lists, and we can
>     adjust the HTTPSSVC draft based on their conclusions.
>
>     On Fri, Jan 3, 2020 at 1:24 PM Paul Vixie <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 3 Jan 2020 15:11:11 -0800

> i'll explain further on the other mailing list that the HTTPSSVC co-chair

It means it would prevent using other ports inside the datacenter.

The WG should not make this change.

Additionally, I am not sure what a "managed private network" is, since the
term seems to imply a lack of privacy.

thanks,
Rob

---

From: Ray Bellis <[email-masked]>
Date: Sun, 5 Jan 2020 18:48:31 +0000

> alternate ports for testing is very common.

Not just for testing - many people use alternate ports when port
forwarding to reach services inside a many-to-one NAT.

Ray