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

Re: #612: 9.2.2 requirements

From: Greg Wilkins <gregw@intalio.com>
Date: Thu, 30 Oct 2014 09:58:31 +1100
Message-ID: <CAH_y2NE+0dv5k+P731TK=pg8Dvj-io7R5657BMQ5gX8EDgZ-iQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
I'm +1 on this.

I think it is good to remove explicit cipher restrictions from this
document, but my primary concern has always been the fragile handshake,
which I think we still have if INADEQUATE_SECURITY is sent.

It is good that we are removing explicit cipher restrictions from this
document as I don't think they belong in an application protocol.  But we
are still allowing implementations to discriminate on the basis of TLS
features by sending an INADEQUATE_SECURITY error, which may then still
result in handshake failure even if there are mutually acceptable
cipher/protocol combinations.

There are definitely many voices here that would like to enforce higher TLS
standards for h2 than h1 and the INADEQUATE_SECURITY error is a mechanism
that remains available for them to do that.  I think that implementations
and/or deployments should be able to impose higher standards without
risking handshake failure, thus I think we still need to make the handshake
more robust in the case of INADEQUATE_SECURITY, - with SHOULD level
requirements about retries and/or h1 fallback.

But If we really cannot guarantee handshake success if an
INADEQUATE_SECURITY is sent (and there are mutually acceptable
cipher/protocol combinations), then we should remove that error code and
put all the security responsibility entirely on the TLS implementation.

regards











On 29 October 2014 20:01, Roland Zink <roland@zinks.de> wrote:

> +1
>
> I think the cipher suites are better handled by TLS and this avoids
> potential problems with ALPN.
>
> Regards,
> Roland
>
>
>
> On 27.10.2014 21:54, Mark Nottingham wrote:
>
>> <https://github.com/http2/http2-spec/issues/612>
>>
>> Reviewing the discussion, I think it’s going to be difficult to declare
>> consensus on 9.2.2 in its current form.
>>
>> Talking through it with a few of the proponents, my proposal to close
>> this issue is to remove 9.2.2 (i.e., the specific requirements on cipher
>> suites), but leave 9.2.1 (the section on TLS features) as-is.
>>
>> Thoughts?
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>
>


-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
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 Wednesday, 29 October 2014 22:59:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:40 UTC