W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Moving forward on improving HTTP's security

From: Mike Belshe <mike@belshe.com>
Date: Thu, 14 Nov 2013 10:22:35 -0800
Message-ID: <CABaLYCs1F+-SUTnwi1+pq2gPUAcw5e6ygjvkCBz7iv7wUtZWrw@mail.gmail.com>
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>
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.


On Thu, Nov 14, 2013 at 10:11 AM, William Chan (陈智昌)

> 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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:38 UTC