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