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

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
<Michael.Bishop@microsoft.com> 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.
>
>
>
> From: Tom Bergan [mailto:tombergan@chromium.org]
> Sent: Wednesday, November 1, 2017 12:30 PM
> To: Mike Bishop <Michael.Bishop@microsoft.com>
> Cc: Martin Thomson <martin.thomson@gmail.com>; Anmol Sethi <me@anmol.io>;
> HTTP Working Group <ietf-http-wg@w3.org>
> Subject: 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 21:43:27 UTC