RE: The HTTP/2 RFC should not mandate RSA certificates

Well, let me put it this way:  The MTI requirement is there to ensure that there will be at least one compatible ciphersuite between clients and servers.  The client doesn’t know what the server’s list is; it knows whether it successfully negotiates a TLS connection or not.  So there’s nothing for the client to enforce; if the server is misconfigured and the client needs the MTI, the connection fails anyway.

On the server side, what does “enforce” mean?  Refusing to accept any connections because there are some it won’t be able to accept is an interesting stance for a networking library to take, and I would argue not one well-suited to being easily included in applications.  Sure, throw a warning if your current configuration means you won’t be able to accept the MTI ciphersuite if it’s offered, and let the administrator deal with that.

I’d suggest treating this like any non-default or non-recommended combination of settings – log a warning if the selected cipher suites and the supplied certificates mismatch, but keep going.

From: Tom Bergan [mailto:tombergan@chromium.org]
Sent: Wednesday, November 1, 2017 12:30 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; Anmol Sethi <me@anmol.io>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: The HTTP/2 RFC should not mandate RSA certificates

On Tue, Oct 31, 2017 at 11:11 AM, Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote:
I think the asserted spec bug is that we implicitly require every server that implements HTTP/2 with TLS 1.2 to possess an RSA certificate.  The day may well come when servers feel comfortable having only an ECDSA certificate, because all the clients they're interested in support them.  And as it stands, to do that, they'd have to also be TLS 1.3-only, which might take a bit longer to be comfortable with.  So instead, they have to possess an RSA certificate to comply with the spec, even if it's never actually used.

It's not a bug in the sense that the spec says something different than we meant it to, but I can see the argument that we made a mistake here.

Regardless, verifying this probably isn't Go's job.

I am curious: Why would you say that it's not the HTTP/2 library's job to verify compliance with that clause in 9.2.2? That clause is a MUST. The best way to verify compliance with a MUST is to fail early and loudly. Otherwise, people will start violating that MUST clause (intentionally or unintentionally) and the world will ossify into a state where the clause is toothless in practice. I'm willing to bet that a large fraction of people running HTTP/2 servers with Go have never read RFC 7540 9.2.2 in detail and would not know about that requirement if it was not enforced by Go's library.

I see an argument for allowing an escape hatch for people who understand the consequences, but that is separate from whether the library should enforce the MTI clause by default.

On Mon, Oct 30, 2017 at 6:26 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
It's admirable that Go wants to police this, but I would have said that it
would be better (and easier) to remove the check and leave the problem
of compliance to deployments.

I'm not sure there is a meaningful difference between a "bit of code that imports Go's http2 library" and a "deployment".