- From: Mike Belshe <mike@belshe.com>
- Date: Thu, 14 Nov 2013 10:22:35 -0800
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: 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>
- Message-ID: <CABaLYCs1F+-SUTnwi1+pq2gPUAcw5e6ygjvkCBz7iv7wUtZWrw@mail.gmail.com>
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:23:03 UTC