Re: Concluding discussion on #612 (9.2.2)

This is a meta-comment.

The current text would requires a cipher suite not available until
Android L [1]. Other options discussed have short-term implementation
risk. I'd suggest that once folks smarter than me decide what the
ideal text is, we add another column to the implementations page, on
that tracks which actually can enforce this.

https://github.com/http2/http2-spec/wiki/Implementations

Hope this suggestion helps,
-A

[1] https://github.com/square/okhttp/issues/959

On Sat, Oct 11, 2014 at 4:03 PM, Jason Greene <jason.greene@redhat.com> wrote:
>
> On Oct 11, 2014, at 5:13 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>>
>> On 11 October 2014 19:35, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>> The whole point is that after TLS stack has negotiated XYZ, the server
>> can't reject it anymore without interop. failure against correct client
>> implementation unless the server actually knows it is not 9.2.2.-acceptable
>>
>> Ilari,
>>
>> OK I get what you are illustrating now.   Yes it is indeed a problem to implement 9.2.2 at all
>> if the server cannot influence the selection of the cipher.
>>
>> But this is an argument against having 9.2.2 at all - as this is a problem that results from making
>> protocol specific cipher requirements in environments where the protocol implementation is not party
>> to the cipher negotiation.
>>
>> Indeed if the client only offers h2, and XYZ and the server has got XYZ in it cipher suites that the TLS
>> layer can accept, but then decides that XYZ is not h2 acceptable - then it is in a mess.        But that
>> problem exists regardless of my proposal for a retry.   The solution to that problem is to not have
>> protocol specific cipher requirements - I'm fully OK with that!
>
> Right, its big a mess. The downgrade attack vectors that Martin refers to are certainly a real issue, and you need [1] to fix it, which TLS 1.3 implementors are looking likely to have (unless they do not support old protocols). So the issue with the “MUST" is we have to also hope that TLS 1.2 stacks also implement this.
>
> If we were after a clean solution, we would simply require TLS 1.3. It’s the right way to mandate TLS 1.3 behavior. It would be great to hear why we simply can’t wait for TLS 1.3 to finish.
>
> Looking at the TLS 1.2 hacks that offer non-fragile handshakes, we have:
>
> 1) Ilari’s modification to your proposal:
>    a) Clients have a white list of h2 accepted ciphers
>    b) Servers have a black list of h2 unacceptable ciphers
>    c) Clients must reconnect if the server doesn’t support those ciphers
>       i) TLS stacks need [1] to mitigate MITM downgrade
> 2) TLS implementations commit to the rich APIs I referred to in an earlier email. According to Michael Sweet’s analysis, nearly all do not. I think it will take quite some time before this is practically available, perhaps when TLS 1.3 is already out.
> 3) Exhaustively specify the allowed ciphers with TLS 1.2 for both client and server, for both H1 and H2. The XYZ cipher scenario above will not be a problem, because the client will be barred from using it, until either TLS 1.3 comes out, or an H2 revision occurs to add it.
>
> Theres one final hack:
>
> 4) Keep a broken spec, and punt to the admin. Basically if the server provides a mechanism to override 9.2.2 in order to fix the version-skew issues then at least its a temporary interop problem. To help the administrator the server could log that it was not familiar with the cipher, and was forced to exclude it.
>
> [1] https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>

Received on Wednesday, 15 October 2014 04:55:49 UTC