TLS ALPN Proposal v5
Simone Bordet
simone.bordet at gmail.com
Fri Sep 25 12:48:18 UTC 2015
Hi,
On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> Maybe, we are not on the same page, I think.
We are.
> I think a general cipher strength comparator is sufficient for HTTP/2
> preference too. What do you think?
I don't know if all the blacklisted ciphers are actually lower
strength of all the remaining ciphers, nor what is the exact
definition of "strength" that you can use in a comparator.
But because the HTTP/2 specification bothered to say what's
blacklisted, I would just use that.
> Maybe, need no extra comparator for HTTP2. Extra comparator would make
> behaviors pretty complicated and hard to get expected, as I described in
> the previous mail.
There is no complication, really. Two comparators would compose, not exclude.
For example, let's say that you want to sort by "bit" strength in a
way that you want to prefer 128 bits or lower to favor performance,
but also do HTTP/2.
The H2 comparator will sort the blacklisted at the end.
Among the good ones, they all compare == 0 for the H2 comparator.
That is where the second comparator will kick in, grep the cipher name
for the bits number and sort them accordingly.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
More information about the security-dev
mailing list