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

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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.
>
> 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