Subject: Working Group Last Call: draft-ietf-httpbis-http2-encryption-04

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Mar 2016 12:22:06 +1100

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04>

Draft -04 offers resolutions for the following design issues:

* "Requiring Use of TLS" - <https://github.com/httpwg/http-extensions/issues/145>
* "Attacks from the same host" - <https://github.com/httpwg/http-extensions/issues/144>

Our issues list for this draft is empty and as I mentioned on another thread, I think this is ready for WGLC. As a reminder, its intended status is Experimental.

Please have a careful read of the draft and raise any remaining issues (either on the issues list or here). If you believe that one of the closed issues isn't adequately resolved, now is the time to say why.  Statements of support / implementation are also welcome.

Because I'm an author on the draft, Mike Bishop is Document Shepherd, and will be judging consensus.

WGLC will end on 1 April 2016.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Mar 2016 12:19:27 +1100

Hi Kari,

> On 18 Mar 2016, at 5:35 AM, Kari Hurtta <[email-masked]> wrote:
> 
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04
> Opportunistic Security for HTTP
> 
> 
> 1)
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-3
> 3. Server Authentication
> 
> 
> |   For example, this request/response pair would constitute reasonable
> |   assurances for the origin "http://www.example.com" for any
> |   alternative service also on "www.example.com":
> |
> |   GET /.well-known/http-opportunistic HTTP/1.1
> |   Host: www.example.com
> |
> |   HTTP/1.1 200 OK
> |   Content-Type: application/json
> |   Connection: close
> |
> |   {
> |     "origins": ["http://example.com", "http://www.example.com:81"]
> |   }
> 
> 
> Origin "http://www.example.com" is mentioned on text,
> Origin "http://www.example.com" is NOT mentioned on /.well-known/http-opportunistic.

Thanks, fixed in -latest.

> 2) 
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-8
> 8. Security Considerations
> 
> For "Attacks from the same host" this makes silent assumption that
> /.well-known/http-opportunistic indicates that there is not injected
> bad Alt-Svc: -headers.
> 
> In other words Alt-Svc: -headers are assumed to be filtered 
> out from attackers (shared hosting), but that assumption is not
> spelled out on draft.

Yes. Any suggested text here (Kari or someone else)?

> 3) 
> 
> I disagree resolution of "Attacks from the same host".
> 
> My long explanation is on
> 
>   Re: [Moderator Action] #144: Attacks from Same Host (OppSec)
>   https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0411.html
>   Message-Id: <[email-masked]> 
> 
> Effectively browser's (or http client's) method to defend this 
> attack is still that browser ignores alternative service 
> if port >= 1024
> 
> If /.well-known/http-opportunistic does not include lists
> alternatives or list of valid ports where alternative service
> is supposed to be located, that ignoring port >= 1024 is best 
> guess what browser can do.
> 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0111.html
> 
> Patrick McManus wrote:
> 
> | I'm actually glad the port number nonsense got called out. It didn't have
> | real value and its the kind of window dressing only a committee could love
> | (I say lovingly, as member of said committee.).
> 
> I'm not sure about that because draft-ietf-httpbis-http2-encryption does not
> provide other defenses for browser.
> 
> I originally suggested that:
> 
> | How about requiring that alternative service are also listed on
> | /.well-known/alternative-services
> | 
> | Pre-Alt-Svc servers do not provide /.well-known/alternative-services
> | and eve can not provide /.well-known/alternative-services on
> | original service.
> | 
> | I think that this stops that attack if http client also checks
> | /.well-known/alternative-services when alternative service
> | does not provide strong auth. This of course adds additional delay
> | before alternative service is used.

Does anyone else agree with Kari's concerns around <https://github.com/httpwg/http-extensions/issues/144>?  If so, now is the time to speak up.

Mike, please track this issue as potentially contentious.

> Current draft does not provide for client means to do check with 
> /.well-known/http-opportunistic resource. Therefore port number
> check is still on table.

Can you please explain what you mean by "Current draft does not provide for client means to do check with /.well-known/http-opportunistic resource."? The draft requires http-opportunistic to be checked when strong authentication is not available. 

> 4)
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
> 5.1. Opportunistic Commitment
> 
> 
> |   An origin can reduce the risk of attacks on opportunistically secured
> |   connections by committing to provide an secured, authenticated
> |   alternative service.  This is done by including the optional "commit"
> |   member in the http-opportunistic well-known resource (see Section 6).
> 
> This does not make possible to specify "commit" without saying same time that 
> there is also reasonable assurance for alternative services for on same host
> which does not provide strong authentication.
> 
> There should be possible to give "commit" for authenticated alternatives
> WITHOUT giving also reasonable assurances for non-authenticated alternatives
> (on same host that origin).
> 
> /.well-known/http-opportunistic SHOULD include separate indication
> that for reasonable assurances. My suggestion for that parameter is same than 
> for "Attacks from the same host".

Raised as <https://github.com/httpwg/http-extensions/issues/160>. Please discuss.

> 5)
> 
> My suggestion for 
> 
>  3. Server Authentication
>  https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-3
> 
> |   When the client has a valid http-opportunistic response for an
> |   origin, it MAY consider there to be reasonable assurances when:
> |
> |   o  The origin and alternative service's hostnames are the same when
> |      compared in a case-insensitive fashion, and
> |
> |   o  The chosen alternative service returns the same response as above.
> +
> +   o  The "valid-ports" member of the root object on the http-opportunistic 
> +      response has a value of an array of numbers, one of which is same
> +      value than alternative service's port number.
> 
>   6. The "http-opportunistic" well-known URI
>   https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-6
> 
> -   This specification defines one additional, optional member of the
> -   root object, "commit" in Section 5.  Unrecognised members MUST be
> -   ignored.
> 
> ⇒
> 
> +   This specification defines two additional, optional members of the
> +   root object, "commit" in Section 5 and "valid-ports" in Section 3.  
> +   Unrecognized members MUST be ignored.
> 
> 
> That "valid-ports" member makes explicit which port numbers are under
> origin's control. So there not need make assumption like port numbers 
> <= 1024 are safe.
> 
> This also makes clear for which purpose /.well-known/http-opportunistic is.
> There is either "commit" or "valid-ports" member on http-opportunistic 
> response. (It is unlikely that both on same time makes sense. )
> 
> Because this also requires that origin and alternative service's hostnames 
> are same, listing port numbers effectively lists alternative
> services (except that protocol is not mentioned, "h2" is only 
> protocol which fulfills requirements). 
> 
> That list of port number or alternative services on http-opportunistic 
> response does not indicate that alternative service is provided on these
> ports, only that alternative services may be provided on these ports
> without valid certificate. This does not replace Alt-Svc: -header field.

This is a proposal for <https://github.com/httpwg/http-extensions/issues/144>, correct?

> 6)
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
> 5.1. Opportunistic Commitment
> 
> 3. Server Authentication requires that
> 
> | The chosen alternative service returns the same response as above.
> 
> Should there be same requirement before "commit" is accepted ?
> Now that is not required for commit.

It's required for server authentication so that there's an assurance that both the origin and alternative opt into the equivalence.

What function would it serve for the commitment?

Thanks for the feedback,

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 17 Mar 2016 18:36:17 +0000

1)

2) 

3) 

Patrick McManus wrote:

4)

5)

My suggestion for 

 3. Server Authentication

⇒

6)

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 21 Mar 2016 04:34:31 +0000

Summary of my previous answers (was not posted to list).

> Thanks, fixed in -latest.

OK.

> Yes. Any suggested text here (Kari or someone else)?

Not really, but I try anyway

---------------------
CGI [RFC 3875], PHP, and other environments allows page
authors to insert custom headers to HTTP -response. Page
authors may also able listen local ports via these 
environments directly or they can execute programs. 

These allows attacker to inject Alt-Svc: which specify
local port on control of attacker on same host.
Without precautions this allows attacker masquerade as the 
HTTP server.

Presence of /.well-known/http-opportunistic tells
that server is aware of that protocol and have take
precautions so that attacker can not masquerade as the 
HTTP server.

Clients can reduce this risk by limiting ports which 
them accept as alternative service on same host (without
valid certificate).

Server can reduce this risk by restricting the ability to
advertise alternative services, and restricting who can 
open a port for listening on that host.
-----------------------

If you can use CGI to execute scripts, you quite likely
have also ability to listen ports. And PHP have
socket_listen()

http://php.net/manual/en/function.socket-listen.php

Then there is Java based environments also.

I do not claim that shell access is required for that
attack.

I borrowed some text from other drafts.

> Can you please explain what you mean by "Current draft does not provide for client means to do check with /.well-known/http-opportunistic resource."? The draft requires http-opportunistic to be che…

I'm not sure that have I left someting out.

/.well-known/http-opportunistic tells that there is SOME
alternative service for that origin.

/.well-known/http-opportunistic does not make possible
to check, if that alternative service, which is
mentioned on Alt-Svc: -header field, is authoritative
for whole origin. 

That /.well-known/http-opportunistic may mean some
other alternative service. (And if there is "commit"
member or perhaps(?) some other (future) member,
it even may not mean any same host 
alternative service. )

Client just knows that there exists some alternative 
service which is authoritative for whole origin.

So client need guess what alternative services
are authoritative.

Possibilities include:

1) It can just trust  
     Alt-Svc: -header field

2) It can try check that itself,
  and make guess that users on web host
  can not bind ports < 1024

3) It can decide to trust just
  some Alt-Svc: -header fields
  on places where is unlikely
  that users on web host
  can introduce them. For example
  GET /
  OPTIONS *
  GET /.well-known/{anything}

I talk checking that alternative service
mentioned on Alt-Svc: -header field is 
same alternative service than what for 
/.well-known/http-opportunistic exists.

I talk checks which browser can do
to defend agaist attack (as opposite
just trust that web host knows and
does all defending agaist attack). 

( I'm not sure if "authoritative"
 is correct term here or if it
 also means something else. )

So this perhaps is question that how alternative 
service authorize itself to client without 
certificate. Can client ask authorization
for alternative service from third party
(that is /.well-known/http-opportunistic ).

If third part ( /.well-known/http-opportunistic )
just gives blanket authorization for all
possible alternative services, I think
that this is murky.

> Raised as <https://github.com/httpwg/http-extensions/issues/160>. Please discuss.

( My replies about this was to another mail. )

> This is a proposal for <https://github.com/httpwg/http-extensions/issues/144>, correct?

Yes, "valid-ports" is my proposal for "Attacks from same host #144"

And it is also for https://github.com/httpwg/http-extensions/issues/160
" Commit without same-host opt-in #160 ":

| /.well-known/http-opportunistic SHOULD include separate indication that for reasonable 
| assurances. My suggestion for that parameter is same than for "Attacks from the same host".

Any parameter which explicity says "same-host opt-in" works for #160.

Implicit parameters (aka "same-host opt-in" if there is no "commit")
do not work as well (Martin Thomson seems disagree with this).

> What function would it serve for the commitment?

Does it make sense to use commintment if 
alternative service does not provide 
equivalent data ?

It may be strange situation for example
if origin says commit but that does not have on
alternative service's response.

> Thanks for the feedback,

Correspond mails should be includes on below (may
be visible as attachment on some mail clients. )

/ Kari Hurtta

> Yes. Any suggested text here (Kari or someone else)?

Not really, but I try anyway

---------------------
CGI [RFC 3875], PHP, and other environments allows page
authors to insert custom headers to HTTP -response. Page
authors may also able listen local ports via these 
environments directly or they can execute programs. 

These allows attacker to inject Alt-Svc: which specify
local port on control of attacker on same host.
Without precautions this allows attacker masquerade as the 
HTTP server.

Presence of /.well-known/http-opportunistic tells
that server is aware of that protocol and have take
precautions so that attacker can not masquerade as the 
HTTP server.

Clients can reduce this risk by limiting ports which 
them accept as alternative service on same host (without
valid certificate).

Server can reduce this risk by restricting the ability to
advertise alternative services, and restricting who can 
open a port for listening on that host.
-----------------------

If you can use CGI to execute scripts, you quite likely
have also ability to listen ports. And PHP have
socket_listen()

http://php.net/manual/en/function.socket-listen.php

Then there is Java based environments also.

I do not claim that shell access is required for that
attack.

I borrowed some text from other drafts.

/ Kari Hurtta

Mark Nottingham <[email-masked]>: (Fri Mar 18 03:19:27 2016)
> Can you please explain what you mean by "Current draft does not provide for client means to do check with /.well-known/http-opportunistic resource."? The draft requires http-opportunistic to be che…

I'm not sure that have I left someting out.

/.well-known/http-opportunistic tells that there is SOME
alternative service for that origin.

/.well-known/http-opportunistic does not make possible
to check, if that alternative service, which is
mentioned on Alt-Svc: -header field, is authoritative
for whole origin. 

That /.well-known/http-opportunistic may mean some
other alternative service. (And if there is "commit"
member or perhaps(?) some other (future) member,
it even may not mean any same host 
alternative service. )

Client just knows that there exists some alternative 
service which is authoritative for whole origin.

So client need guess what alternative services
are authoritative.

Possibilities include:

1) It can just trust  
     Alt-Svc: -header field

2) It can try check that itself,
  and make guess that users on web host
  can not bind ports < 1024

3) It can decide to trust just
  some Alt-Svc: -header fields
  on places where is unlikely
  that users on web host
  can introduce them. For example
  GET /
  OPTIONS *
  GET /.well-known/{anything}

I talk checking that alternative service
mentioned on Alt-Svc: -header field is 
same alternative service than what for 
/.well-known/http-opportunistic exists.

I talk checks which browser can do
to defend agaist attack (as opposite
just trust that web host knows and
does all defending agaist attack). 

( I'm not sure if "authoritative"
 is correct term here or if it
 also means something else. )

So this perhaps is question that how alternative 
service authorize itself to client without 
certificate. Can client ask authorization
for alternative service from third party
(that is /.well-known/http-opportunistic ).

If third part ( /.well-known/http-opportunistic )
just gives blanket authorization for all
possible alternative services, I think
that this is murky.

/ Kari Hurtta

Quick note. Not posted to list.

> This is a proposal for <https://github.com/httpwg/http-extensions/issues/144>, correct?

Yes, "valid-ports" is my proposal for "Attacks from same host #144"

And it is also for https://github.com/httpwg/http-extensions/issues/160
" Commit without same-host opt-in #160 ":

| /.well-known/http-opportunistic SHOULD include separate indication that for reasonable 
| assurances. My suggestion for that parameter is same than for "Attacks from the same host".

Any parameter which explicity says "same-host opt-in" works for #160.

Implicit parameters (aka "same-host opt-in" if there is no "commit")
do not work as well (Martin Thomson seems disagree with this).

/ Kari Hurtta

> What function would it serve for the commitment?

Does it make sense to use commintment if 
alternative service does not provide 
equivalent data ?

It may be strange situation for example
if origin says commit but that does not have on
alternative service's response.

/ Kari Hurtta

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Mar 2016 15:19:14 +0200

Hi there,

see below for mostly editorial feedback (in document order)...

Best regards, Julian

-- snip --
1.  Introduction

    This document describes a use of HTTP Alternative Services
    [I-D.ietf-httpbis-alt-svc] to decouple the URI scheme from the use
    and configuration of underlying encryption, allowing a "http" URI
    [RFC7230] to be accessed using TLS [RFC5246] opportunistically.

NIT: expand "TLS" on first use (the mention in the abstract IMHO does 
not count)

    Opportunistic Security [RFC7435] does not provide the same guarantees
    as using TLS with "https" URIs; it is vulnerable to active attacks,
    and does not change the security context of the connection.
    Normally, users will not be able to tell that it is in use (i.e.,
    there will be no "lock icon").

    By its nature, this technique is vulnerable to active attacks.  A
    mechanism for partially mitigating them is described in Section 5.

NIT: the first sentence just repeats something already stated in the 
paragraph before.

3.  Server Authentication

    As defined in that specification, one way of establishing this is
    using a TLS-based protocol with the certificate checks defined in
    [RFC2818].  Clients MAY impose additional criteria for establishing
    reasonable assurances.

NIT: second sentence repeats normative language from alt-svc. Just use 
prose to point that out instead.

    When the client has a valid http-opportunistic response for an
    origin, it MAY consider there to be reasonable assurances when:

Q: I assume that refers to the response to a GET on the well-known URI? 
(the example supports that, but then, it's just an example...)

4.  Interaction with "https" URIs

    Since "https" URIs rely on server authentication, a connection that
    is initially created for "http" URIs without authenticating the
    server cannot be used for "https" URIs until the server certificate
    is successfully authenticated.  Section 3.1 of [RFC2818] describes
    the basic mechanism, though the authentication considerations in
    [I-D.ietf-httpbis-alt-svc] also apply.

NIT: make that reference more specific.

    Connections that are established without any means of server
    authentication (for instance, the purely anonymous TLS cipher
    suites), cannot be used for "https" URIs.

NIT: comma seems to be misplaced.

    An origin can reduce the risk of attacks on opportunistically secured
    connections by committing to provide an secured, authenticated

s/an/a/

    alternative service.  This is done by including the optional "commit"
    member in the http-opportunistic well-known resource (see Section 6).
    This feature is optional due to the requirement for server
    authentication and the potential risk entailed (see Section 5.3).

s/optional/OPTIONAL/?

    o  The client has obtained a 200 (OK) response for the well-known URI
       from the origin, or refreshed one in cache [RFC7234], and
    o  That response has the media type "application/json", and

Q: maybe this should use a custom media type.

    o  That response's payload, when parsed as JSON [RFC7159], contains
       an object as the root.
    o  The "origins" member of the root object has a value of an array of
       strings, one of which is a case-insensitive character-for-
       character match for the origin in question, serialised into
       Unicode as per [RFC6454], Section 6.1, and

Q: list truncated?

    This specification defines one additional, optional member of the
    root object, "commit" in Section 5.  Unrecognised members MUST be
    ignored.

7.  IANA Considerations

    This specification registers a Well-known URI [RFC5785]:

    o  URI Suffix: http-opportunistic
    o  Change Controller: IETF
    o  Specification Document(s): [this specification]

NIT: make reference more specific.

8.2.  Downgrade Attacks

    A downgrade attack against the negotiation for TLS is possible.  With
    commitment Section 5, this is limited to occasions where clients have

NIT: weird section link.

    no prior information (see Section 8.3), or when persisted commitments
    have expired.

8.3.  Privacy Considerations

    Cached alternative services can be used to track clients over time;
    e.g., using a user-specific hostname.  Clearing the cache reduces the
    ability of servers to track clients; therefore clients MUST clear
    cached alternative service information when clearing other origin-
    based state (i.e., cookies).

Q: is this a new normative requirement, or does it just restate what 
alt-svc says?

8.4.  Confusion Regarding Request Scheme

    Many existing HTTP/1.1 implementations use the presence or absence of
    TLS in the stack to determine whether requests are for "http" or
    "https" resources.  This is necessary in many cases because the most
    common form of an HTTP/1.1 request does not carry an explicit
    indication of the URI scheme.

    HTTP/1.1 MUST NOT be used for opportunistically secured requests.

    Some HTTP/1.1 implementations use ambient signals to determine if a
    request is for an "https" resource.  For example, implementations
    might look for TLS on the stack or a port number of 443.  An
    implementation that supports opportunistically secured requests
    SHOULD suppress these signals if there is any potential for
    confusion.

This section looks a bit unstructured. Paragraph 3 seems to restate what 
Paragraph 1 already says.

Paragraph 2 IMHO needs to be clearer: it refers to the protocol used to 
perform the opp-sec-ed request, not the original one, right? FWIW, I 
still think that the reasoning for this is weak (an HTTP/2 server stack 
might suffer from the same problem), and thus should either be relaxed, 
or better explained.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Mar 2016 11:42:40 +1100

Thanks Julian,

You can find this all on
https://github.com/httpwg/http-extensions/pull/164.  Feel free to
merge if you are happy and we can continue with the remaining changes.

On 31 March 2016 at 00:19, Julian Reschke <[email-masked]> wrote:
> Q: I assume that refers to the response to a GET on the well-known URI? (the
> example supports that, but then, it's just an example...)

Yes, done.

>    authentication and the potential risk entailed (see Section 5.3).

I think that I've learned to hate RFC 2119.

> 6.  The "http-opportunistic" well-known URI
[...]
> Q: maybe this should use a custom media type.

I'm not sure what that buys us.

>       Unicode as per [RFC6454], Section 6.1, and

I don't think so.  Mark can you confirm?

> Q: is this a new normative requirement, or does it just restate what alt-svc
> says?

Yes, it is repetition.  I think that we can remove this, Mark?

> perform the opp-sec-ed request, not the original one, right? FWIW, I still
> think that the reasoning for this is weak (an HTTP/2 server stack might
> suffer from the same problem), and thus should either be relaxed, or better
> explained.

I've restructured this and explained the distinction between discovery
and use a little better, but I'm not going to change the fundamentals
here.  We've gone over that point a fair number of times already and I
thought that we had reach some sort of pseudo-acceptable (if weak)
compromise position on it.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Mar 2016 08:54:33 +0200

> https://github.com/httpwg/http-extensions/pull/164.  Feel free to

Thanks, and...

> merge if you are happy and we can continue with the remaining changes.

...done.

> ...
> ...

With the latest changes, this now reads:

"Some HTTP/1.1 implementations use ambient signals to determine if a 
request is for an https resource. For example, implementations might 
look for TLS on the stack or a port number of 443. This is necessary in 
many cases because the most common form of an HTTP/1.1 request does not 
carry an explicit indication of the URI scheme. An implementation that 
is serving an opportunistically secured request SHOULD suppress these 
signals for http resources.

HTTP/1.1 MUST NOT be used to serve opportunistically secured requests. 
HTTP/1.1 can be used to discover an opportunistically secured 
alternative service."

The problem remains that this is not really specific to HTTP/1.1; for 
instance, code running inside Apache over HTTP/2 may have exactly the 
same problem (Stefan E. to confirm); so it's more a matter of HTTP 
server internal APIs, not the on-the-wire protocol.

I believe this needs to be rephrased to better explain the actual 
problem; and I also remain unconvinced that the conclusion wrt HTTP/1.1 
makes sense.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Mar 2016 18:29:03 +1100

On 31 March 2016 at 17:54, Julian Reschke <[email-masked]> wrote:
> I believe this needs to be rephrased to better explain the actual problem;
> and I also remain unconvinced that the conclusion wrt HTTP/1.1 makes sense.

Maybe I'm a little too close to this now.  I can't see how I might
rephrase this differently.  Do you have a suggestion?

I also would prefer not to have a carve-out for HTTP/1.1 here.  If you
want to ask the question again, I look to our chair (and shepherd) for
guidance.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Mar 2016 14:53:25 +0200

> rephrase this differently.  Do you have a suggestion?

We need to start with a precise problem description. The spec currently 
says:

signals for http resources."

This is IMHO misleading. The problems are:

- the wire protocol might not carry the URI scheme (as is the case with 
the most common HTTP/1.1 form of request targets)

- the API implemented by the HTTP server for the code running inside it 
may not carry the scheme name

- ...and even if it does, the code might not handle it properly (maybe 
because it was written for 1.1 and never updated)

- in absence of a specific scheme indicator, the HTTP server, or the 
modules running inside the server, might make use of ambient signals.

So there are many things that can go wrong, and they are not restricted 
to the use of HTTP/1.1 as wire protocol.

> want to ask the question again, I look to our chair (and shepherd) for

The WG can of course can decide to rule out HTTP/1.1 for this use case. 
But if it does, the spec should be clear about why that is the case. I 
*believe* the answer is: "because the likelihood that things aren't 
handled properly is higher requests over HTTP/1.1".

On the other hand: if I wanted to opp-sec HTTP/1.1 over port 80 to 
HTTP/1.1 over TLS over port 81, what would be the harm?

Best regards, Julian