All that is true.  However, it's not an issue of QUIC.  Yes, having transport-level encryption would make sense to make those things easier to do "the right way" -- and part of what QUIC provides is making it harder to do "the wrong way."  "The right way" is an HTTP-level concern (how clients and proxies interact), not a transport-level concern (clients talk to proxies and servers in the same way).

-----Original Message-----
From: Adrien de Croy [] 
Sent: Sunday, March 12, 2017 2:33 PM
To: Poul-Henning Kamp <>; Mike Bishop <>
Cc: Alex Rousskov <>; Patrick McManus <>; HTTP working group mailing list <>
Subject: Re: on HTTP/QUIC and HTTPBis

Yes, I think if we take the starting point that

* a company that is worried about cyber-slacking of employees
* a school worried about students surfing porn
* a mom and dad worried about their kids spending too much time watching minecraft videos on youtube

are going to block sites _no_matter_what_ we do, then we should make it possible to do this cleanly, and reliably without having to resort to nasty tricks.

Because if we don't allow people to block at protocol level, they will block at transport level, which will result in over-blocking, and very poor user experience.  It is not our place to say people should not block, and deny people the facility to do it properly, we are here and involved in protocol work for the people.  This includes people who need for completely legitimate reasons to block things.


------ Original Message ------
From: "Poul-Henning Kamp" <>
To: "Mike Bishop" <>
Cc: "Alex Rousskov" <>; "Patrick McManus" <>; "HTTP working group mailing list" 
Sent: 11/03/2017 8:07:29 PM
Subject: Re: on HTTP/QUIC and HTTPBis

>In message
>>, Mike Bishop writes:
>>  I'm sympathetic to the lack of configured proxies' abilities to,  
>> with user/client awareness, monitor the contents of transactions  
>> which are otherwise encrypted and return meaningful errors.  I'm  
>> less sympathetic to middleboxes that act without client awareness  or 
>> configuration.
>If so, wouldn't it make sense to proactively make it easier to roll out 
>the former than the latter, rather than make it equally hard ?
>Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>phk@FreeBSD.ORG         | TCP/IP since RFC 956
>FreeBSD committer       | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by 

Received on Monday, 13 March 2017 17:40:08 UTC