Re: #612: 9.2.2 requirements

> On Nov 5, 2014, at 8:01 AM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> On 5 November 2014 16:31, Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> wrote:
> You are implying that TLS_RSA_WITH_AES_128_CBC_SHA is known insecure. This is not the case.
> 
> Not at all.
> 
> I'm saying that it allows a h2 handshake to include weak ciphers for the purposes of h1 fall back:
>    Clients MAY advertise support of cipher suites that are prohibited by
>    the above restrictions in order to allow for connection to servers
>    that do not support HTTP/2.  This enables a fallback to protocols
>    without these constraints without the additional latency imposed by
>    using a separate connection for fallback.
> This is the clause that causes the handshake to be fragile, because the ALPN protocol does not support differing cipher sets for each protocol.     So it is not possible for a server to distinguish between a unknown cipher being offered as a h2 cipher or as a h1 fallback.
> 
> There are two linked conversations going on.  One about what ciphers we should (or should not) restrict and one about the handshake. Some are trying to argue that the definition of what ciphers to restrict is crystal clear and future proof, so that the fragile handshake is not a problem.         They may well be right, but they cannot prove that to be the case.  Thus I am arguing that the handshake should be fixed - so that if the future of ciphers does turn out to be less than crystal clear then the result not a handshake failure.
> 
> If we have a robust handshake, then I am prepared to accept cipher restrictions recommended by experts  even though I do not believe they belong in an application protocol.
> 
> Without a robust handshake, I am not prepared to even attempt getting involved in cipher negotiations. Jetty will just try to use whatever the TLS layer negotiates regardless of protocol.

Then we’re on the same page. I think the sanest way to implement this is to have the HTTP implementation ignore ciphersuites entirely and have the TLS layer know which ciphersuites go with h2 and which go only with h1.

That’s an ugly hack IMO because a TLS library should be generic - good for HTTP, SMTP, our proprietary protocol for managing firewalls. Placing HTTP/2-specific logic in it is an ugly hack, but it’s better than adding multiple APIs.

Yoav