Expand connection management text #1024
Conversation
draft-ietf-quic-http.md
Outdated
| any requests for which the client considers the server authoritative. | ||
|
|
||
| This typically means that the client has received an Alt-Svc record from the | ||
| request's origin in question which nominates the server endpoint as a valid HTTP |
There was a problem hiding this comment.
This is potentially misleading. Alt-Svc doesn't form the basis for authority. I understand the intent here is to say that you don't get here without Alt-Svc, but the "This" in this sentence is immediately after the bit about authority.
There was a problem hiding this comment.
"This" does in fact refer to considering the server authoritative, so you're reading it correctly. RFC 7838 does say that Alt-Svc provides authority.
Alternative services are considered authoritative for an origin's resources....
There was a problem hiding this comment.
I think that we're talking past each other. The alternative is not authoritative because of Alt-Svc, that authority derives from the certificate. This text implies that it derives from Alt-Svc, which is dangerously misleading.
There was a problem hiding this comment.
Perhaps. I think this is an area that's in flux right now -- example.com:443 is authoritative for https://example.com/, but the certificate validates that you're actually talking to example.com:443. Under any previous RFC, a server isn't authoritative simply because it has the certificate.
Alt-Svc allows an authoritative server to say that otherguy.org:8080 is co-authoritative with it. You still need to validate the cert to verify that you've successfully reached the authoritative alternative, but it is the Alt-Svc delegation that makes it authoritative. The certificate simply proves identity when connecting to that authoritative endpoint.
ORIGIN makes the stronger statement that a server can be authoritative simply because it has the certificate, if the client chooses to play by those new rules. That's a new assertion in RFC [TBD], but not something contained in any existing RFC that I'm aware of.
I'll add some text saying that, as required by RFC 7838, the client MUST ensure that the certificate is valid for the origin being requested.
There was a problem hiding this comment.
Overall I think this does address the issues indicated. Some remaining questions that maybe don't need to be answered here:
- are there any special considerations for connection reuse for 0-RTT or 1-RTT?
- RFC7540 also describes connection reuse in terms of the CONNECT method and Proxies, is that still applicable?
draft-ietf-quic-http.md
Outdated
| connection establishment, HTTP/QUIC support is indicated by selecting the ALPN | ||
| token "hq" in the crypto handshake. | ||
| token "hq" in the crypto handshake. Support for other application-layer |
There was a problem hiding this comment.
nit: s/crypto/cryptographic to better align with Transport doc terminology. Seems like an opportunity to fix it up while in this area.
There was a problem hiding this comment.
How about "TLS," since I've already said we're bound to that anyway? ;-)
draft-ietf-quic-http.md
Outdated
|
|
||
| HTTP/QUIC relies on QUIC as the underlying transport. The QUIC version being | ||
| used MUST use TLS version 1.3 or greater as its handshake protocol. The Server | ||
| Name Indication extension {{!RFC6066}} MUST be included in the TLS handshake. |
There was a problem hiding this comment.
I missed the SNI reference because the acronym was not used, may help to add (SNI).
RFC7540 also says clients MUST indicate target domain when negotiating TLS, is that requirement inherited here?
There was a problem hiding this comment.
I tried a couple of different wordings with the requirement on what to include in SNI, but nothing felt right. (Particularly in light of the Alt-Svc SNI draft, which suggests that the SNI might be something to which you don't actually intend to direct requests.) I ultimately decided to leave it at MUST use the extension and MUST make sure you've seen a valid cert for an origin before using the connection for it. If those two are related or not is a case-by-case choice by the implementation.
draft-ietf-quic-http.md
Outdated
| has received an Alt-Svc record from the request's origin which nominates the | ||
| endpoint as a valid HTTP Alternative Service for that origin. As required by | ||
| {{RFC7838}}, clients MUST validate that the nominated server can present a | ||
| validated certificate for the origin before considering it authoritative. |
There was a problem hiding this comment.
"validate a validated certificate" sounds odd.
|
Planning to merge soonish, unless @martinthomson is still unhappy with the authority text or someone else squawks. |
|
|
||
| An authoritative HTTP/QUIC endpoint is typically discovered because the client | ||
| has received an Alt-Svc record from the request's origin which nominates the | ||
| endpoint as a valid HTTP Alternative Service for that origin. As required by |
There was a problem hiding this comment.
should we use "server" here rather than "endpoint"?
There was a problem hiding this comment.
What led me to that wording is that the same server might offer both TCP(HTTP/2) and UDP(QUIC) endpoints, so we're not necessarily discovering a new server. It's ultimately an IP:port that we're connecting to, and I think "endpoint" is a more accurate term there. Alternate terms for that concept welcome.
draft-ietf-quic-http.md
Outdated
| endpoint as a valid HTTP Alternative Service for that origin. As required by | ||
| {{RFC7838}}, clients MUST check that the nominated server can present a valid | ||
| certificate for the origin before considering it authoritative. Clients SHOULD | ||
| NOT assume that an HTTP/QUIC endpoint is authoritative for other origins without |
There was a problem hiding this comment.
"SHOULD NOT assume"? "cannot" or "MUST NOT" perhaps
There was a problem hiding this comment.
Yeah, I don't remember what my logic was for that one. Probably trying to dance around the ORIGIN-style trust model. Either is fine.
|
@MikeBishop I'm not that familiar with SNI, but if it is required, will it work in scenarios where HTTP is not using name based addressing, such as in a RPC server cluster where only IP addresses are used for identification? |
|
That's a good question -- the HTTP/2 language is
I assume that's currently working for you...? |
|
That won't work, because SNI can't technically hold a IP literal. However, it is common for clients to accept IP addresses in subjectAltName. The only option there - if you care about compliance - is to make up an SNI (use the named from the reverse DNS tree perhaps) and to have the server effectively ignore the SNI and provide the IP-based certificate. Practically speaking, if you don't have a name, then omitting SNI is probably fine. Yet another reminder that this ecosystem is full of landmines. |
|
By omission, do you mean an empty sni extension value, or no extension at all? Http/Quic sounds looser than Http/2 "The Server Name Indication (SNI) extension [RFC6066] MUST be included in the TLS handshake." |
|
Yes, and that isn't accurate - it implies that the server is also bound by the requirement - which is technically allowed for servers, but the extension is rarely sent (it makes no sense for a server to send it). |
(Fixes #940, #794)
Adds the requirement for TLS as the handshake protocol (agreed in Chicago, but never added to draft), use of SNI, and discusses connection reuse aspects we've probably all been assuming but never wrote down.
I feel like we might still need a stronger text than "QUIC as the underlying transport," since HTTP/QUIC technically has a dependency on the ability for the client to initiate bidirectional streams and the server to initiate unidirectional streams. There's no guarantee that arbitrary QUIC versions would include that, so we perhaps should state it.