RE: http/2 and TLS security

Think of TLS negotiation as a menu -- the client offers a whole set of things it supports.  The server then chooses the combination of things that it wants, and informs the client of its decision.  That applies to both your questions -- from the list the client sends, the server selects TLS version (greatest version both it and the client support), cipher suite, and application protocol.

It would be a client error to offer TLS 1.1 and h2, but not a fatal one.  The server selects both the TLS version and the protocol from what the client offers.  So it would be a *server* error to select an invalid combination; a compliant server would just ignore the offer of h2 in a TLS 1.1 ClientHello.

The same applies to the second one -- the client offers lots of cipher suites, including ones that are only supposed to be used with HTTP/1.1.  When the server selects, it should select a cipher suite and protocol combination that's valid.  The SHOULD/MAY are there because some TLS stacks aren't actually able to do that -- negotiation happens in the TLS layer, which doesn't know these rules, and then the HTTP layer doesn't have any control until it sees the result of the negotiation.  At that point, the server can't do anything and it's back to the client's decision whether or not to proceed with the connection having seen the results of the handshake.

If you have an architecture like that, your best option on the server is simply to prioritize the permitted cipher suites.  If the client supports them, you'll pick one.  And since clients that support HTTP/2 are required to support at least one of these cipher suites, it becomes a non-issue with compliant clients.  Yes, the list of good cipher suites is a little short these days.

-----Original Message-----
From: Francisco Moraes [mailto:francisco.moraes@gmail.com] 
Sent: Tuesday, November 3, 2015 11:59 PM
To: ietf-http-wg@w3.org
Subject: http/2 and TLS security

Hi,

I have a few questions from a server perspective when implementing http/2:

1. if http/2 is selected to be supported, TLS 1.2 is required, but that doesn't mean that the server cannot negotiate TLS 1.x with clients that are not talking h2. It would be a client error to negotiate TLS 1.1 for example if it wants to talk h2. Should the server close the connection is for some reason TLS 1.1 or 1.0 was negotiated for http/2?

2. Appendix A of RFC 7540 lists a lot of ciphers that are black listed but the wording says the server MAY treat the negotiation of the ciphers with TLS 1.2 as a connection error. This doesn't imply that I should disallow those ciphers in my server configuration, but I have seen some of those ciphers cause an error on the client side (browser). What's the best practice here? Print a warning if those ciphers are used? Fail? 
Failing every single one of those ciphers leaves a very limited list of ciphers to be used.

Francisco

Received on Tuesday, 3 November 2015 15:40:54 UTC