Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication

[Nicolas Mailhot <[e-mail]>]

Willy Tarreau <w <at> 1wt.eu> writes:

Hi Willy

> On Fri, Apr 27, 2012 at 09:16:00AM +0000, Nicolas Mailhot wrote:

> > Would it be possible to publish a list of specific questions and have each
> > proposal submitter answer how its proposal answers each of them? 
> 
> I'm not sure this will help make great progress in the short term (only 1.5
> month is left for proposals, and working on them takes a *lot* of time).

Maybe, but in the long term, this kind of question will need answering anyway,
so it's dangerous to postpone them IMHO. That adds the risk of painful later
reworks if something is missed in the initial phases.


> > 1. Can the proposal permit secure http/2.0 communication without letting
> > malware punch random protocols through firewalls using the http/2.0 secure
> > port?

> You'll never ever be able to guarantee this. 

Right but there is a difference between allowing some leaking, and being so lax
one can push full vpn/remote desktops through the https port. If one of the
proposals improve this situation that would be a definite plus.

> > 2. How can intermediary network nodes request (re-)authentication on secure
> > networks when client credentials expire?
> 
> Unless I miss your point, that's what the 401 is about, no ?

The point is proxy/gateway auth as before. Especially for proposals that push
for full TLS encryption, when it is the most broken case right now.

Right now most browsers propose opening an http connection to a specific URL to
trigger portal auth. That's broken by design (http and https are different
namespaces, and different URIs may be subjected to different filtering)
and instead of fixing this some of the proposals make the situation
worse as far as I can tell.

> > 3. How can they communicate authentication location to the client 
> > 4. How could other intermediary messaging be handled?
> 
> I'm not sure I get these points.

Again, how can proxies and gateways communicate with the web client. Or to put
it otherwise: is the proposal compatible with Enterprise network security or
does it require changes elsewhere that may or may not happen while Enterprise
users get cut from the new http/2 web?

For example if a proposal requires a new proxy protocol to be proxified the
proxy protocol changes should be submitted alongside it, not in some
hypothetical future.

> > 5. Is the proposed protocol feature-complete or does it require an http/1.1
> > downgrade to handle some existing http use-cases (esp. proxy ones)?
> 
> It needs to be able to completely replace it otherwise it will mean much
> more work for many implementers, leading to many more bugs and interop
> issues.

I agree but I'm sure some answers to 2. will be 'open an url to
http://youre-on-the-internet.com/ in http 1.1'. And there may be other cases
I'm not aware of.

> > 8. Does it add specific logging constrains that didn't exist in http/1.1?
> Logging is out of the scope of HTTP in my opinion 

If you add multiplexing, logging (and log processing) needs reworking. How much
depends on how the proposed multiplexing works. Implementers (both server,
intermediary and client side) need to be informed of the new elements that need
logging now

> > 9. How will the proposal improve network efficiency?
> At least by reducing message sizes, packet counts and connection counts.

This is the only question reasonably answered in the proposals though not two
proposals address it the same way

Regards,

-- 
Nicolas Mailhot