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.


Per RFC7838 client does not need even read
It is enough that there is valid certificate.

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


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 

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

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



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