- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Thu, 14 Nov 2013 12:37:12 -0600
- To: Mike Belshe <mike@belshe.com>
- Cc: William Chan (陈智昌) <willchan@chromium.org>, James M Snell <jasnell@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Sweet <msweet@apple.com>, Nicolas Mailhot <nicolas.mailhot@laposte.net>, Willy Tarreau <w@1wt.eu>, Tao Effect <contact@taoeffect.com>, Tim Bray <tbray@textuality.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
What about web interfaces on home devices, like routers. They could benefit from HTTP/2.0, but not so much from TLS. On Thu, Nov 14, 2013 at 12:22 PM, Mike Belshe <mike@belshe.com> wrote: > Printers can just use HTTP/1.1 if they don't want to use TLS, just like they > can use HTTP/1.0 if they don't support HTTP/1.1 > > But plenty of printers today already support https. Enterprises already > have needs for encrypted data to the printer. The fact that TLS is hard to > deploy there is not a new problem nor relevant to HTTP2 - its not like we > should reduce security to printers because TLS was hard. The owners of > those printers still have legal needs for TLS :-) > > Using TLS everywhere will make it easier for these folks because the tooling > will get better. > > Mike > > > > On Thu, Nov 14, 2013 at 10:11 AM, William Chan (陈智昌) <willchan@chromium.org> > wrote: >> >> I think this is a great question. I confess not to be super familiar with >> the printing space, which is why Michael's repeated comments in this working >> group have been very useful. I would say that my teammates and I have not >> considered this issue very much, and my default inclination is to tell IPP >> folks to stick with HTTP/1.X if they only want to support cleartext. If they >> want HTTP/2, then they should solve the blockers to adopting a secure >> transport. I realize this is a difficult thing to say to them, and I am open >> to considering other options, but my teammates and I really do care about >> moving all communications over a secure transport, and holding firm to the >> stance of only supporting HTTP/2 over a secure transport is one of our best >> mechanisms to incentivize folks to tackle the hard problems that block >> secure transport (TLS or what have you) adoption. >> >> Cheers. >> >> On Thu, Nov 14, 2013 at 9:09 AM, James M Snell <jasnell@gmail.com> wrote: >>> >>> Ok, so this raises the question. For clarification it would be great >>> if some of the folks from Chromium or Firefox could answer this: >>> >>> - The proposal that Mark put on the table is HTTP2 over HTTPS Only >>> for open Internet traffic. >>> - William has said that Chromium, at least, will ONLY support HTTP2 >>> over HTTPS, period, without any qualification given about "open" or >>> "private" internet traffic, >>> >>> Therefore, it would be helpful to know... >>> >>> - If my printer running on my secure local wifi network hosts an >>> HTTP/2 server without using TLS, will I be able to use Chrome to >>> access my printers HTTP/2 server. >>> >>> If not, then we have a definite problem. >>> >>> >>> - James >>> >>> On Thu, Nov 14, 2013 at 9:02 AM, Stephen Farrell >>> <stephen.farrell@cs.tcd.ie> wrote: >>> > >>> > Just on two points... >>> > >>> > On 11/14/2013 04:41 PM, Michael Sweet wrote: >>> >> The point of all this is just that adding/requiring TLS for HTTP/2.0 >>> >> does not, by itself, make HTTP/2.0 more secure, >>> > >>> > Adding even opportunistic encryption does make things more secure. >>> > Nobody sensible said anything makes things "secure" without some >>> > qualification. >>> > >>> >> and that deploying >>> >> TLS properly is not as simple as clicking a button. Last week the >>> >> prevailing assumption was that “active attacks are too expensive”, >>> > >>> > That's not correct. Lots of discussion last week related to making >>> > pervasive attacks more expensive which is very different to the above. >>> > For example active attacks are much more detectable and hence >>> > riskier which is very different. >>> > >>> > Having said that I do agree that the printer/device-as-server >>> > issue is a real one. >>> > >>> > S >>> > >>> >> but in the last couple days we have discovered that assumption is not >>> >> correct and that MITM proxies are widely deployed already. >>> > >>> > >> >> >
Received on Thursday, 14 November 2013 18:37:39 UTC