RE: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Building on Kari's feedback below, advertising an alternative with protocol "h2" (or "http/1.1") isn't really an opt-in for this specification.  Such a server could legitimately be implementing RFC 7838 as-is, which does not forbid offering that response.  (In fact, it's an explicit example given in section 2!)  You opt in to supporting this specification by having a resource at /.well-known/http-opportunistic, unless we wanted to mint a new a new Alt-Svc parameter for the origin and only host the resource on the alternative.

I agree with Kari as well that the text as-written applies to http:// schemed URIs being served over any TLS-based transport.  We might want to generalize that latter section to something like "over a connection consistent with the https:// scheme" or something like that.

More generally, I still disagree with the quoted MUST NOT on the grounds that it's unenforceable and not a hard requirement for interoperability.  Clients that implement only RFC 7838 will inherently violate the MUST NOT, and the server has no way of distinguishing those clients from implementations of this spec.  SHOULD NOT acknowledges that it's undetectable, while still emphasizing that there are risks associated to doing it this way.

Taking a step back, what is the list of ports actually buying us now?  The port can be obtained by the client from the Alt-Svc header.  The fact that the port is legitimate and not hijacked is verified by finding that it has a certificate.  What we're actually confirming is that the origin supports mixed schemes.  The lifetime is already present in the Alt-Svc advertisement, and I haven't heard a compelling reason to have a separate lifetime.  Should we just define SETTINGS_MIXED_SCHEME_PERMITTED and call it a day?

-----Original Message-----
From: hurtta@hurtta09lk.keh.iki.fi [mailto:hurtta@hurtta09lk.keh.iki.fi] On Behalf Of Kari hurtta
Sent: Tuesday, October 4, 2016 9:03 AM
To: HTTP working group mailing list <ietf-http-wg@w3.org>
Cc: Kari hurtta <hurtta-ietf@elmme-mailer.org>
Subject: Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt


> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07

2.  Using HTTP URIs over TLS
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07#section-2

|    An origin server that supports the resolution of "http" URIs can
|    indicate support for this specification by providing an alternative
|    service advertisement [RFC7838] for a protocol identifier that uses
|    TLS, such as "h2" [RFC7540].

This allows also other than "h2" (for example "http/1.1", which is HTTP/1.1 over TLS).

2.1.  Alternative Server Opt-In
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07#section-2.1

|    Clients MUST NOT send "http" requests over a connection with the "h2"
|    protocol identifier, unless they have obtained a valid http-
|    opportunistic response for an origin (as per Section 2.3), and:

But this part is specific to "h2".


What part of this specification is valid when prococol identifier is not "h2" ?

/ Kari Hurtta

Received on Tuesday, 4 October 2016 17:39:21 UTC