W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

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

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Tue, 31 Oct 2017 18:11:09 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Anmol Sethi <me@anmol.io>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <MWHPR21MB0141EDF64E1035ED86BEE908875E0@MWHPR21MB0141.namprd21.prod.outlook.com>
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:martin.thomson@gmail.com] 
Sent: Monday, October 30, 2017 6:27 PM
To: Anmol Sethi <me@anmol.io>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 <me@anmol.io> 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://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.
> 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

Received on Tuesday, 31 October 2017 18:11:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 November 2017 00:14:14 UTC