Re: #612: 9.2.2 requirements

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.


On 29 October 2014 20:01, Roland Zink <> 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:
>> <>
>> 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

Greg Wilkins <>  @  Webtide - *an Intalio subsidiary* HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Wednesday, 29 October 2014 22:59:00 UTC