W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: null ciphers in 9.2.2

From: Greg Wilkins <gregw@intalio.com>
Date: Sat, 27 Sep 2014 07:16:25 +1000
Message-ID: <CAH_y2NGmWZASjG9vsW=2rTPc9WX74E22JTTjbCP-kJVcUf7nGw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
My comments in the other thread are very much about IF we are to restrict
ciphers can we at least do so in a non fragile way.

My response here is do we really really have to have 9.2.2?

Enforcing strong ciphers is targeted at trying to make main stream
deployments better, but a whole bunch of niche use-cases are going to be
innocent bystanders that are outlawed by 9.2.2.

For example, using null ciphers for debugging purposes is now a casualty of
9.2.2.  I'm sure there are other niche use-cases that will probably be
taken out.

I totally get why you want to have 9.2.2, but the application protocol us
just the wrong place to try to do it and I think we are yet to have an idea
of how deep the unintended consequences will be.

regards


On 27 September 2014 01:49, Martin Thomson <martin.thomson@gmail.com> wrote:

> As a clarification, I think that we need to be sure to say that the
> null cipher is not permitted.
>
> Technically, the null cipher is a stream cipher, but this isn't made
> explicit in the draft.
>
> I'm going to add this to the chain of changes I have for 9.2.2, since
> I hate managing conflicts.  So it won't hit the main spec until we
> resolve that issue.
>
>


-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Friday, 26 September 2014 21:16:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC