- From: Greg Wilkins <gregw@intalio.com>
- Date: Sat, 27 Sep 2014 07:16:25 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NGmWZASjG9vsW=2rTPc9WX74E22JTTjbCP-kJVcUf7nGw@mail.gmail.com>
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