Guidance for port number use

[MikeBishop]

Extracting this issue from Ben's #424 so we don't block an otherwise-simple change:

There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. #424 updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case.

This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify).

On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.)

[mikkelfj]

There is also the related concern where a protocol such as HTTP/QUIC expects the user to know the port and where Alt-Svc is explicitly not supported. Here silence can be a response when the client does not authenticate in order to hide from malicious parties such as ever present port scanners.

[mirjak]

This sounds like something that could be discussed in the applicability statement

[martinthomson]

If we're going to recommend or otherwise encourage changing ports, then that's definitely going to have an impact on manageability. Not just from the perspective of "how do I identify QUIC", but also from the perspective of "how do I deploy a server using QUIC" - for the reasons @MikeBishop describes.

There are a bunch of subtle issues about authoritative use here that get gnarly. I don't think that these are insurmountable issues, but we would need to be careful, and I've been stung on this before. Alt-Svc was not the doddle I originally imagined.

The port that can speak for a name over HTTP is now carried in a whole different protocol. There are now quite a few protocols that rely on mapping from a name to a URL using .well-known, which wouldn't work for QUIC without a well-known port. In a way we would be strengthening our reliance on our fallback protocol if we insist on randomizing.

As Mike notes, it is much, much easier if we leave things as they are. Maybe that doesn't cause ports other than the one we nominate to loosen up, but it would be good to understand what perceived benefits derive from that. For someone looking to use other ports, more use of non-443 ports might be good, but it's rare that the need is "use a particular port number" as opposed to something else. Understanding what that something else might be would probably help.

[bemasc]

There are now quite a few protocols that rely on mapping from a name to a URL using .well-known, which wouldn't work for QUIC without a well-known port. In a way we would be strengthening our reliance on our fallback protocol if we insist on randomizing.

Could you give an example? Most .well-known uses I know of already have a port in addition to the name. Also, we could require SRV records when using QUIC in contexts where the port is unknown.

it would be good to understand what perceived benefits derive from that. For someone looking to use other ports, more use of non-443 ports might be good, but it's rare that the need is "use a particular port number" as opposed to something else. Understanding what that something else might be would probably help.

Needs I perceive:

• Run a server as non-root without making clients do something unusual and poorly supported. IMHO, requiring privilege to run an HTTP server (on port 80 or 443) has been a nontrivial cause of vulnerabilities in low-budget webservers. Running HTTP on other ports is possible, but is not well-supported by clients (e.g. users can't just type a domain name into a URL bar).
• Do P2P QUIC without fighting network ossification. P2P QUIC could be useful for WebRTC-like applications, which will necessarily run on high-numbered ports. Keeping those flows identical to client-server QUIC would help us avoid the kind of ossification that required awful workarounds in WebRTC, like ssltcp and TURN-TLS candidates.
• Multihosting QUIC on IPv4 without SNI. Making the port a first-class component of any QUIC address would give CDNs the option to offer each customer an isolated 3-tuple (IP, UDP, port) for QUIC serving, avoiding reliance on SNI (at least in QUIC).

[MikeBishop]

Run a server as non-root....

This is a separate issue again. By using Alt-Svc to find the HTTP/QUIC endpoint, we're still requiring that the authoritative server be on TCP 80 or 443. Which means you still need whatever privileges are required to do that, at least on the authoritative endpoint. Sure, you can run alternatives with less privilege, but that doesn't help the "vulnerabilities in low-budget webservers."

Multihosting QUIC on IPv4 without SNI....

This seems already achieved by your pull request. By highlighting that the alternative can be on any port, the CDN is free to use ports however it wants, including handing out individual ports to individual origins. Of course, there's the grease piece of this, in that if it's not actively exercised, it's unlikely to keep working, so someone should start doing this early.

Do P2P QUIC without fighting network ossification.

This, to me, is the big argument for a "SHOULD randomize" suggestion for server operators.

[hardie]

While I like this point with my RTCWEB chair hat on:

"Do P2P QUIC without fighting network ossification. P2P QUIC could be useful for WebRTC-like applications, which will necessarily run on high-numbered ports. Keeping those flows identical to client-server QUIC would help us avoid the kind of ossification that required awful workarounds in WebRTC, like ssltcp and TURN-TLS candidates."

It makes my ACME chair hat hurt me because I think it might make constructing a challenge using QUIC very difficult to get right. With the Alt-Svc approach and HTTP, you will get the authoritative server options based on the control of TCP 443, so you can finesse it here. But it may be less easy to finesse with other protocols using QUIC.

@bifurcation can you take a look at this?

[bemasc]

I see your point regarding ACME. It seems to me that you are describing a hypothetical future in which QUIC is the definitive endpoint for some domain. My feeling right now is that how you view our options in that future depends on how much you like SRV records.

[martinthomson]

@hardie hit on an issue that I thought about a bit, but as long as we go to TCP first, I can't see QUIC having any role here. The URI scheme kinda determines that. This is why I understand why @MikeBishop wants to mint a new scheme, but it doesn't make me any more inclined to think that it will succeed.

As for running services on ports <1024, as long as you have root access once, it's possible to run a userland service, see https://serverfault.com/a/112798 for example. Most servers use setuid() instead, of course. That suggests to me that issues with running as root is completely workable from a security perspective.

The ossification question seems to be the most relevant question. I agree with Ted about the value for WebRTC in having an unmodified protocol. Though we might find some of the mechanisms we build are duplicative and so we have to disable certain things (consent to send is pretty tightly integrated into WebRTC; we have very little of that in QUIC now, but probably will build something).

[igorlord]

@bemasc

Multihosting QUIC on IPv4 without SNI.

I believe TLS 1.3 requires SNI, and QUIC requires TLS 1.3, so SNI is required for QUIC. Is that incorrect?

[janaiyengar]

@igorlord Yes, QUIC requires TLS1.3 (and therefore SNI).

[igorlord]

Thank you, @janaiyengar !

[martinthomson]

TLS 1.3 does not require that SNI be used. HTTP/2 does. We won't be picking up the TLS usage requirements from h2, mainly because TLS 1.3 invalidates virtually all of them. Mandatory SNI is one that we won't get.

@igorlord, can you open an issue to track this. I don't think that there was ever any intent to differ from HTTP/2 on this point, but we need to make sure that we don't lose it.

[RyanTheOptimist]

On Sun, Sep 24, 2017 at 9:50 PM, Martin Thomson ***@***.***> wrote: TLS 1.3 does not require that SNI be used. HTTP/2 does. We won't be picking up the TLS usage requirements from h2, mainly because TLS 1.3 invalidates virtually all of them. Mandatory SNI is one that we won't get.

I think I hear you saying that QUIC doesn't currently require SNI. But could QUIC require SNI?

[martinthomson]

The only reason it doesn't is because we haven't written it down. I believe that the intent is to require SNI.

[RyanTheOptimist]

Carry on, then!

[MikeBishop]

Transferred to quicwg/ops-drafts#26.