W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

From: Simone Bordet <simone.bordet@gmail.com>
Date: Wed, 24 Sep 2014 11:39:53 +0200
Message-ID: <CAFWmRJ2_-UQ+ATxXh0zuNihnSCQ3BhXP4dSA2Q7gL9XS6YORSw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
Hi,

On Wed, Sep 24, 2014 at 11:26 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 24 September 2014 02:23, Simone Bordet <simone.bordet@gmail.com> wrote:
>> A polyglot client that can speak multiple protocols (e.g. h1, h2)
>> cannot just disable ciphers globally only because one of those
>> protocols has special needs, also considering the client has no idea
>> what protocol will be chosen.
>
> But a polyglot can ensure that it understands the implications of
> enabling suite X before it does so.  For all of the protocols it
> speaks.

Can you expand on what you mean here ?

I don't understand exactly what you mean by "software that understands
implications of enabling a cipher it does not know".
If it does not know the cipher, how can it understand any implication
of enabling it ?

Are you suggesting that every h2 client must be modified (and
recompiled if it needs to) every time a new cipher is provided by TLS,
or I totally misunderstood you (sorry if it is so) ?

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
Received on Wednesday, 24 September 2014 09:40:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC