Re: #612: 9.2.2 requirements


>> On Oct 31, 2014, at 11:12 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>> 
>> On 31 October 2014 20:49, Jason Greene <jason.greene@redhat.com> wrote:
>> My point is that a legacy compatible client advertises cipher suites that aren’t compatible with H2 before H2 is selected. This is in contrast to a 1.3 client that would advertise 1.3 ciphers, and use SCSV fallback for pre 1.3 ciphers, which is a much more robust handshake, and leaves the TLS cipher selection where it belongs.
> 
> That's not right.  A 1.3 client will offer cipher suites that are only
> supported in 1.2 and earlier because a round-trip is a high price to
> pay for guessing wrong.  What you suggest would basically prevent 1.3
> from ever being deployed.
> 
> The 1.3 handshake will be compatible with all 1.2 and earlier servers
> (assuming that they are not version or extension intolerant...i.e.,
> not broken).

Ah yes, you are right. I was under the mistaken impression that there was a desire to discourage these ciphers, but I suppose the reality is clients would be blamed for this cost, so they will always include. Further it doesn't really matter whether they are included or not since they will always be in the right order, and the TLS implementation has all the knowledge and facilities to properly reject the wrong cipher with the wrong TLS.

Reconsidering Brian's argument regarding ALPN behavior, it's perfectly plausible that a TLS impl could validate the ALPN + cipher combination and ensure either the right ciphers are chosen, or that the ALPN missing the proper cipher requirements is not selected by the application. Following this line of thought I must concede that there is no TLS protocol problem. 

In fairness, the issue instead a practical one (the lack of support by TLS implementations, and the inability of H2 implementations to comply with these rules at the time of H2 standardization)

Received on Saturday, 1 November 2014 13:52:05 UTC