> due to the limited cipher suites in the RFC With this point, I just wanted to say, I have to agree fully. The requirements that get forced on folks just to a

> due to the limited cipher suites in the RFC With this point, I just wanted to say, I have to agree fully. The requirements that get forced on folks just to adopt HTTP/2 are frustrating. As much as I also like PFS, tying HTTP/2 to it was silly, IMO. If the old ciphers are really that bad, I wish the vendors would just commit to that and put out a timeline for deprecating them. But this "they're only bad if you're using HTTP/2" to me seems like a nonsense carrot and stick. > client side certificates, or encrypted keys These aren't particular to HTTP/2 though; you can use or not use them equally the same w/ HTTP/1.x. (In particular, client certs aren't going to effect most people.) > How do you test TLS? LetsEncrypt rate limits cert creation. For the purpose of CI, there isn't an easy way to get trust on both sides. Unit test become a pain, so people just don't encrypt. Testing your certificate issuance stuff is orthogonal to HTTP/2, again, is it not? Outside of ensuring you get the appropriate key usage bits set on the certificate, I don't see why it shouldn't be very feasible, for testing HTTP/2, to simply mock out LE w/ a self-signed certificate.