Subject: Re: The HTTP/2 RFC should not mandate RSA certificates

From: Tom Bergan <[email-masked]>
Date: Wed, 1 Nov 2017 12:29:34 -0700

On Tue, Oct 31, 2017 at 11:11 AM, Mike Bishop <[email-masked]>
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 <[email-masked]>
 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".

---

From: Mike Bishop <[email-masked]>
Date: Wed, 1 Nov 2017 20:21:37 +0000

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:[email-masked]]
Sent: Wednesday, November 1, 2017 12:30 PM
To: Mike Bishop <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Anmol Sethi <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: The HTTP/2 RFC should not mandate RSA certificates

On Tue, Oct 31, 2017 at 11:11 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> 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.

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 <[email-masked]<mailto:[email-masked]>> 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".

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Nov 2017 08:43:04 +1100

If you want to maintain some level of enforcement, it's possible to
add a yes_I_know_Im_violating_the_RFC_but_disable_the_mandatory_RSA_ciphersuite()
function somewhere as an explicit way to opt out of enforcement.
Still, if it exists, that enforcement shouldn't be wrong.

On Thu, Nov 2, 2017 at 7:21 AM, Mike Bishop
<[email-masked]> wrote:
> 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.
>
>
>
> 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
> 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.
>
>
>