Issues with ALPN implementation in JDK 9

[Simone Bordet]

Hi,

On Wed, Jun 15, 2016 at 8:12 PM, Jason Greene <jason.greene at redhat.com> wrote:
> Here is an H2 example:
>
> The ClientHello expressing interest in both h2, and h1, and lists the ciphers:
>     TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>
> So in this case the client is expressing a preference for a CBC cipher using stronger keys, but is blacklisted by h2 due to not being GCM, but this is allowed by h1. The JDK will follow the client hello as the TLS spec describes, and so it will select TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, and the protocol stack will incorrectly select h1.
>
> Now technically H2 clients can avoid this by ordering h2 compliant ciphers on top, but they might not do so.
>
> The flaw really starts to show when you have multiple alternative protocols with completely different requirements. As an example, if you have a hypothetical protocol which does not perform certificate based authentication, and instead utilizes pre-shared keys or anonymous ciphers, that protocol can never be selected unless those algs are on the top of the list, if they are on the top of the list then h2 can’t be selected.
>

I'm not sure what you want to show here.
If you want to prefer ciphers, you have to give up on protocol and
viceversa, that's normal business.

If there is no decision, then there is a conflict; if there is a
decision, then the solution I propose works equally well to what you
guys propose.

There is no "flaw", it is just undecidable.
What am I missing ?

Thanks !

-- 
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