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

Updated 9.2

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 10 Oct 2014 10:41:48 -0700
Message-ID: <CABkgnnW9J-LEarDU5GGzdVHXmTxV72YXbMzu3HZ=50h6bXiJaQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, Greg Wilkins <gregw@intalio.com>
I've updated my pull request to include some of Greg's editorial
feedback, as well as collect the input from the last few weeks of
discussion. It's still a relatively small section, but we've done a
lot of talking and this is hard to get right.

These are the changes of note:

 - All of the TLS usage restrictions only apply to TLS 1.2 (TLS 1.3
won't permit all these things anyway), except the SNI requirement

 - Added explicit permission to fall back to HTTP/1.1
   -- There is a risk of a modest form of downgrade attack here that
I've identified

 - Added a recommendation to order cipher suites with preferred ones first

 - Prohibited the advertisement or selection of cipher suites that are
not known to conform to the cipher suite restrictions

 - Reduced the ECDHE security level to 112

 - A few editorial tweaks for clarity

Note:
I haven't taken Greg's suggestion to limit fallback to the case where
clients offer legacy suites for HTTP/1.1 servers.  As Ilari notes,
this doesn't help if you have independent TLS stacks that are using
suites that you don't understand.  Instead, this is a blanket
permission: if you see INADEQUATE_SECURITY, either from the server, or
you are forced to generate it, then you MAY fallback.

We could soften the prohibition on suites with unknown properties and
rely more on INADEQUATE_SECURITY to cover us.  My preference is to not
do that, because it creates a loophole, but I'd like input on that.
Received on Friday, 10 October 2014 17:42:23 UTC

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