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

From: Anmol Sethi <[email-masked]>
Date: Mon, 30 Oct 2017 18:58:37 -0400

Hello,

Late last year, I submitted a patch to Go’s HTTP/2 library to allow the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher as an alternative MTI cipher to the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher that the HTTP/2 RFC mandates.

My reasoning for this patch is that many servers only use ECDSA certificates and so the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher will never be used in those situations and thus we should allow TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as an alternative MTI cipher.

See https://go-review.googlesource.com/c/net/+/30721 <https://go-review.googlesource.com/c/net/+/30721> for further information and discussion.

After some discussion and feedback on my patch, it seems this may be a spec bug.

So is this a spec bug? Is it alright to allow TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as an alternative MTI cipher?

Regards,
Anmol

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Oct 2017 12:26:42 +1100

It's not a spec bug.  Though you may use this cipher suite (it's not
prohibited), it's not mandatory to implement or use.

Note that HTTP/2 mandates *availability* of
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, not just implementation.  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.  Having a check that is also wrong sends
the wrong message to users of the stack.  It says that my
configuration is OK because Go said so, when it won't necessarily
interoperate because Go used a check that is inconsistent with the
published RFC.

Now, if we had a process to easily change the spec, I would say that a
change like this would be fine, but even then we might be getting
ahead of ourselves.  See <https://mzl.la/2gOeX7h>, which shows a ratio
of approximately 1:3 of ECDSA vs RSA.  Note that 1 =
ssl_auth_rsa_decrypt (i.e., static RSA) and 7 = ssl_auth_rsa_sign
(i.e., ECDHE_RSA).

On Tue, Oct 31, 2017 at 9:58 AM, Anmol Sethi <[email-masked]> wrote:
> Hello,
>
> Late last year, I submitted a patch to Go’s HTTP/2 library to allow the
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher as an alternative MTI cipher
> to the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher that the HTTP/2 RFC
> mandates.
>
> My reasoning for this patch is that many servers only use ECDSA certificates
> and so the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher will never be used
> in those situations and thus we should allow
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as an alternative MTI cipher.
>
> See https://go-review.googlesource.com/c/net/+/30721 for further information
> and discussion.
>
> So is this a spec bug? Is it alright to allow
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as an alternative MTI cipher?
>
> Regards,
> Anmol

---

From: Mike Bishop <[email-masked]>
Date: Tue, 31 Oct 2017 18:11:09 +0000

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.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, October 30, 2017 6:27 PM
To: Anmol Sethi <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: The HTTP/2 RFC should not mandate RSA certificates

It's not a spec bug.  Though you may use this cipher suite (it's not prohibited), it's not mandatory to implement or use.

Note that HTTP/2 mandates *availability* of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, not just implementation.  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.  Having a check that is also wrong sends the wrong message to users of the stack.  It says that my configuration is OK because Go said so, when it won't necessarily interoperate because Go used a check that is inconsistent with the published RFC.

Now, if we had a process to easily change the spec, I would say that a change like this would be fine, but even then we might be getting ahead of ourselves.  See <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmzl.la%2F2gOeX7h&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C4da2b80d6da245fe7dfe08d51fff7499%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450104421738192&sdata=XAc0u9OxXcqAEmXDrNLy3VGcl8uAcB2VjmAWH9JHS1M%3D&reserved=0>, which shows a ratio of approximately 1:3 of ECDSA vs RSA.  Note that 1 = ssl_auth_rsa_decrypt (i.e., static RSA) and 7 = ssl_auth_rsa_sign (i.e., ECDHE_RSA).

On Tue, Oct 31, 2017 at 9:58 AM, Anmol Sethi <[email-masked]> wrote:
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher as an alternative MTI 
> cipher to the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher that the 
> HTTP/2 RFC mandates.
>
> My reasoning for this patch is that many servers only use ECDSA 
> certificates and so the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher 
> will never be used in those situations and thus we should allow
> See 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo-review.googlesource.com%2Fc%2Fnet%2F%2B%2F30721&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C4da2b80d6da245fe7dfe08d51fff7499%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450104421738192&sdata=fbOvVDWTKhw%2FfYk8EgqSQEuk19i6rAFxGir6MN4aY2I%3D&reserved=0 for further information and discussion.
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Nov 2017 10:26:07 +1100

On Wed, Nov 1, 2017 at 5: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.

Yes, I can see that this is something that could be perceived as a
problem.  But the choice was explicit (at least for those of us who
understood the implications of the text at the time, which I will
concede probably wasn't everyone involved).

As far as it goes, there are deployments where ECDSA is entirely
sufficient already.  But those deployments should be content in being
non-compliant on this particular requirement, valuing as they do
performance - or whatever else it is that motivates this thread - over
interoperability.