Re: HTTP2 allowed ciphers

by the way I dont know whether this has been discussed but instead of just
throwing INADEQUATE_SECURITY the clients should show WHAT is inadequate,
this is the same problem with many warnings (e.g. in probably many browsers
a warning about certificate validity expired or not started doesnt give the
user a hint about that the clock may just be set wrongly) when showing it
it should show the specifif ciphers that are blacklisted so it gets easie
rto kick them off the server (or just down some priorities).

2016-04-30 0:17 GMT+02:00 Martin Thomson <martin.thomson@gmail.com>:

> That option was discussed, but the working group decided that this
> leads to uncertainty about which ciphers are blacklisted.  The h2
> implementation is often independent of the TLS implementation and
> therefore might not have the same understanding of what is on the list
> and not.  That uncertainty means that you can get INADEQUATE_SECURITY
> errors where you don't expect them.
>
> On 29 April 2016 at 23:18, Philipp Junghannß <teamhydro55555@gmail.com>
> wrote:
> > well okay, that makes sense but even the blacklist will probably change
> over
> > time when new stuff comes in
> > (e.g. if the h2 blacklist would have been made before EC was a thing,
> > probably any EC+RC4 would have to have been added later on, or another
> > example, chacha/poly probably comes in the future, but nobody wants to
> have
> > anon+chacha/poly that's why it will have to get kicked into oblivion as
> > well)
> > because all combinations with RC4, MD5 other and stuff have to be
> avoided,
> > so technically it might be simpler for the blacklist to say that anything
> > RC4, SHA1 and so on is forbidden, also since some servers seem to have
> > shortcuts for that.
> >
> > so TLDR:
> > instead of
> >
> >> TLS_DH_anon_WITH_RC4_128_MD5
> >> TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
> >> TLS_DH_anon_WITH_DES_CBC_SHA
> >> TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
> >> TLS_KRB5_WITH_DES_CBC_SHA
> >
> > and so on.
> > just use
> >
> >> Key exchange:
> >> PSK, anon
> >>
> >> Cipher:
> >> RC4, DES, 3DES
> >>
> >>
> >> Mac:
> >> MD5, SHA1
> >
> > and so on.
> >
> > that makes it a lot easier to consume and understand why a lot of the
> > ciphers are there even though they might look well at first glance.
> >
> > also such a shortcutted list makes it a lot easier to read and makes the
> > server configs shorter meaning they can be easier to understand without
> > having a to check why there are 276 blacklisted ciphers and later
> relaizing
> > "oh that just the h2 blacklist"
> >
> > Regards
> >
> > 2016-04-29 14:17 GMT+02:00 Amos Jeffries <squid3@treenet.co.nz>:
> >>
> >> On 29/04/2016 10:33 p.m., Philipp Junghannß wrote:
> >> > I have read the forbidden ciphers for HTTP2 (appendix A) which is
> quite
> >> > a
> >> > long list and I think it might be intresting to see what ciphers
> >> > actually
> >> > ARE allowed, also because whitelisting a small number of ciphers might
> >> > be
> >> > more efficient than blacklisting everything that's listed there
> >> > (especially
> >> > concidering the different naming conventions among servers.
> >> >
> >>
> >> The result of that test depends on your library and its age. IIRC you
> >> will find that AEAD, EC, DH or AES GCM based ciphers are almost the only
> >> allowed ones. Those are all fairly recent developments and not available
> >> on OS more than a few years old.
> >>
> >> (One would expect that any OS getting updated to software doing h2 is
> >> also capable of getting security library updates. But weirder things
> >> have happened in HTTP.)
> >>
> >> The blacklist set is fixed, whereas the whitelist is variable and must
> >> also cope with a group of not-yet-invented ciphers. Figuring out that
> >> variable part on the go can be a lot less efficient than using a static
> >> blacklist and leaving the details to the library.
> >>
> >> It is up to you how to implement of course. Just saying blacklist is
> >> actually the easy way. You can also shortcut the list somewhat - notice
> >> that CBC, RC4, etc. are common occurance on the forbidden so just making
> >> your software avoid old cruft will get you a long way towards compliance
> >> and will help with general HTTPS security as well.
> >>
> >> Amos
> >>
> >>
> >
>