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>
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>
 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".

Received on Wednesday, 1 November 2017 19:30:01 UTC