- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Fri, 4 Dec 2015 10:49:47 +0000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Adrien de Croy <adrien@qbik.com>, Jacob Appelbaum <jacob@appelbaum.net>, Mike Belshe <mike@belshe.com>, Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
- Message-Id: <245746A1-A574-4D19-A8AA-8AC5270D0D8F@lukasa.co.uk>
> On 4 Dec 2015, at 06:39, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > -------- > In message <em716fa71d-9378-436e-b0c9-5a505cd8614b@bodybag>, "Adrien de Croy" w > rites: > >> As for "fixing the political issue", that is not our job at all. > > I would like to advocate the stance I have taken from the start of > my open source involvement: > > "We deliver tools, not policies" > > Precisely the illadviced "SSL/TLS" everywhere policy being shoved > down peoples throat is a very good example of why. Hang on a moment. Poul-Henning, you and I agree on very little (which is fine, disagreement is healthy), but I think we agree that the TLS-everywhere policy pressured the Kazakh government to make this move. I personally believe they’d have done this eventually *anyway*, and we definitely disagree on whether TLS-everywhere is a good idea in the face of this move, but we can agree on that point. However, I want to point out that *this working group* has, to my knowledge, never enacted any requirement that could be referred to as mandating, or even particularly encouraging, TLS-everywhere. RFC 7540, the most recent product from this group, quite expressly allows for plaintext HTTP/2: it even specifies how to negotiate and use it. That support exists in the wild, today: my implementations can do plaintext HTTP/2, several of the server implementations can do it, and I’ve used it on the open web myself. As I understand it, your objection is not with *this working group*, it is with specific implementations (and possibly their representatives on this working group). Browsers and servers choose to restrict themselves to TLS-transports: the products of this WG do not mandate it. As a result, I believe a large chunk of the content in this thread is off-topic for this WG, and strictly on-topic for the mailing lists of implementations that implement only encrypted H2. I encourage those with concerns to take them to those implementations directly, rather than hoping that their concerns will filter through from representatives on this list. Given that, as far as I can see what you want from this WG is not to stop specifying that TLS must be used everywhere, but to start specifying that implementations MUST support plaintext versions of all protocols they implement. In the absence of normative language, nothing is being shoved down anyone’s throats, at least not by this WG. If you want to avoid TLS-everywhere being "shoved down" everyone’s throat, rather than posting emails that prove how wonderful you are at predicting changes in government policy, you should continue to use your influential voice when new drafts are discussed to ensure that they do not further contribute to the problems you are concerned about. Your voice, amongst others, helped keep a plaintext implementation of HTTP/2 in place in RFC 7540. You have the standards behind you: you can request that implementations relax their TLS-everywhere H2 policy. Other useful actions, if you’re interested in the standards process, might be to consider requesting a revision of BCP 188 to cover your concerns, or proposing an additional BCP document that would help cover it. What is *not* helping is about 50% of this thread, which consists of grandstanding and empty rhetoric. Matthew Kerwin very kindly attempted to shepherd this conversation onto the Encrypted Content-Coding document, and both you and others have provided useful feedback on that draft: that is valuable, thank you. Proposing new drafts or amendments to drafts is also helpful. Complaining about the behaviour of implementations in this forum is not helpful. From where I’m sitting, this working group *does* deliver tools, not policies. As a result, I think your concern is best taken to the IESG or to individual implementations. This email thread is not helping the business of this WG.
Received on Friday, 4 December 2015 10:50:20 UTC