Re: draft-ietf-httpbis-http2-encryption-06.txt

( Using same time "tls-ports" and "tls-commit" member )

| It seems to me that this use of tls-ports is a mechanism to say that
| both an authenticated path is available and certain ports are *not* safe
| to use that way. The parameter name is just very odd for that meaning.
|  
| Use case would along the lines of a load balancer sitting in front of
| the server diverts those ports somewhere else special that has
| authentication but not for the service wanted.

| (just throwing up wild ideas in case nones thought about it yet).

Intresting idea.


So "tls-ports" lists safe ports and that imply that other ports
are not safe to use for that origin.

Was that what you mean ?



I'm not sure that this works.

1) 

Per RFC7838 client does not need even read
/.well-known/http-opportunistic
It is enough that there is valid certificate.

I guess that load balancer can just filter
Alt-Svc: -header fields from response instead.

2) 

If there is no service wanted, then that port
does not include same /.well-known/http-opportunistic
(I guess).


However "tls-commit" does not require that that
alternative port gives same /.well-known/http-opportunistic
representation as the origin did for the http-opportunistic 
resource.

On that case it does make sense to require 
that /.well-known/http-opportunistic are same
on both on alternative and origin.

( I suggested that on
  https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0481.html

| 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.

)

3) 

Currently "tls-ports" does not have specified that way.
It does not have negating power.


/ Kari Hurtta
( Away until 2016-06-27 )

Received on Friday, 24 June 2016 07:52:36 UTC