Re: Discussion of 9.2.2

[Greg Wilkins <[e-mail]>]

On 25 September 2014 18:30, Martin Thomson <[e-mail]> wrote:

> Based on this discussion, I think that there needs to be a d) here
> where we note that implementations MUST NOT offer cipher suites where
> these properties (PFS, stream/block mode) are unknown.  This was an
> assumption on my part that turns out to be important.  With that
> change, I think that the concern about fragility becomes immaterial.
>


I think that something like that, if it applies to all offered protocols,
will help a bit with the fragility issue.  What that effectively means is
that weak ciphers for h1 fallback can only be offered if they are known by
the client to be non-h2 compliant.

If the server receives an unknown cipher, then it cannot accept h2 on it
and should thus avoid INADEQUATE_SECURITY.  The server will then only
accept h2 if it knows the cipher to be good and it can be reasonably
confident that the client will not be offering a h2 acceptable cipher
unknowingly

However I still have several lingering concerns:

   - Black listing ciphers for which properties are unknown may be a
   significant impediment to the adoption of new better cyphers.
   - Implementations that do not have direct access to the properties of a
   cipher will still probably resort to black/white listing of h2 acceptable
   ciphers.   It will be impossible to prevent such configuration breaking
   your rule d), however having such a configuration will at least reduce the
   barrier to introducing new ciphers...  So INADEQUATE_SECURITY can still
   occur if such configurations are over zealously updated in contradiction to
   9.2.2
   - I am concerned that "No block/stream ciphers except AEAD" is a
   sufficiently future proof specification.  Could there be block/stream
   ciphers that use something other than AEAD to make them sufficiently strong
   for h2?  If so, how would such ciphers be knowingly included?
   - Rather than whitelisting h2 ciphers based on their properties, would
   it not be simpler to.

So a similar counter proposal would be to replace c) with an explicit white
list of currently known weak ciphers that can be offered for h1 fallback.
This list would be immutable as it only exists to transit from known weak
ciphers.

This would give certainty to the sever side if they receive an unknown
cipher.  Since it is unknown, it is not in the h1 fallback whitelist, so it
is not being offered for h1 only.    Thus the server knows that if it
accepts it for h2 the client will also accept it (otherwise it would not
have been offered).

Both the client and server would then be empowered to have their own policy
on using unknown ciphers.  Clients can choose not to offer unknown ciphers
and servers can choose not to accept them.  But the key here is that this
choice is made independent of any protocol selection and can be achieved
through existing white/black list configuration.

regards


















-- 
Greg Wilkins <[e-mail]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.