- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 5 Nov 2014 23:16:24 -0600
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Patrick McManus <mcmanus@ducksong.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
MAY makes more sense. You want servers to validate ciphers, but without the proper TLS hooks, this needs to be limited to rejecting known bad ciphers. As previously discussed, when the client white lists, and the server black lists, you end up with the exact same security as the the current draft, but instead with a robust handshake. This is the thinking behind #639, which is very similar to what you propose. > On Nov 5, 2014, at 9:28 PM, Mark Nottingham <mnot@mnot.net> wrote: > > Dare I say MAY? > >> On 6 Nov 2014, at 2:10 pm, Patrick McManus <mcmanus@ducksong.com> wrote: >> >> >> On Wed, Nov 5, 2014 at 7:02 PM, Mark Nottingham <mnot@mnot.net> wrote: >> So, maybe the path forward would be to leave the cipher suite requirements at MUST -- putting the responsibility for conforming on the administrator in some deployments -- but reduce the requirement to generate INADEQUATE_SECURITY to a SHOULD, thereby letting an implementation that doesn't have the ability (or desire) to enforce off the hook. >> >> Need to think through the implications of that, but WDYT? >> >> >> I'm assuming the Y in WDYT opened that question up to the room :) >> >> I think this is reasonable on balance. As Martin has already noted we've tended to favor harder error handling requirements but if the practicalities of this protocol requirement mean it will be fulfilled by agreement outside of the h2 implementation (e.g. via config of a coordinated partner application) then it makes sense to be more flexible here wrt generating INADEQUATE_SECURITY. > > -- > Mark Nottingham https://www.mnot.net/ > > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 6 November 2014 05:16:56 UTC