I agree. One actual use case that could be solved in a better way than today would be login portals where a user have to be logged in to access the Internet.

I agree. One actual use case that could be solved in a better way than today would be login portals where a user have to be logged in to access the Internet. Today, this is typically solved by issuing a redirect of some kind to the client (in the future, I guess it will receive a 511). For HTTPS, the choices are a: Dropping the packets, ensuring extra costs in the support organizations when users wonder why their internet doesn't work. b: Doing a MITM and issue a redirect to the login portal that way. Different operators choose different solutions here. Neither choice is good. Having a way of telling the client, that yes, while the connection is still encrypted, it didn't end up at the place it expected. Might it be possible to add to TLS so that there are some way of issuing gateway redirect? Perhaps, perhaps not. I've seen precious little action in that area.